A mobile cache consistency protocol using

A Mobile Cache Consistency Protocol Using Shareable Read/Write Time Locks Abhinav Vora Zahir Tari Peter Bertok Kwong Lai School of Computer Science & Information Technology, Melbourne, Australia favora,zahirt,pbertok,[email protected] Abstract Object caching is often used to improve the performance of mobile applications, but the gain is often lessened by the additional load of maintaining consistency between an original object and its cached copy. This paper aims at reducing the consistency maintenance work and proposes a protocol that distinguishes between two classes of consistency (i.e. weak and strong ) and treats them differently. Strong consistency is used for data that needs to be consistent all the time, whereas weak consistency is for cases when stale data can be tolerated or only specific updates are relevant to the application. Consistency is maintained by using strict and permissive read/write time locks that enable data sharing for a fixed time period and support concurrency control. A notification protocol for propagating updates to clients is also proposed. Performance tests have shown that switching from strong to weak consistency reduces the number of aborts due to conflicting operations by almost half, even with high read/write sharing.

1 Introduction As mobile computing devices are becoming smaller and faster and networks support higher bandwidth and reliability, users with hand-held or laptop devices can be active participants in distributed computing while on the move. Mobile computing is becoming a major player in the computing arena and has a strong impact on how applications are designed. In particular, there are many constraints and restrictions imposed by the mobile and often wireless environment, which include intermittent and weak connections, wide variations from high bandwidth, low latency through low bandwidth, high latency to no connectivity at all [2]. Mobile clients need to maintain continuous operation under a variety of conditions. For example, they may switch between connected and disconnected states to reduce the cost of connection or to overcome availability problems, or can have very weak connections that can not be improved [2].

Disconnected operations are usually supported by replication and object caching on the mobile host. Our focus in this paper is on the approaches proposed in [4] and [3] as they are the most advanced in mobile environments. Pitoura and Bhargava [4] proposed different operations (e.g. weak read/write) in addition to the standard operations. Data located at strongly connected sites are grouped together to form clusters. Mutual consistency is required for copies in the same cluster, while degrees of consistency are tolerated for copies in different clusters. Weak operations are supported within the same cluster, allowing operations on locally available data. Weak reads access inconsistent copies and weak writes make conditional updates. Lee et al. [3] suggest an approach to maintaining (cache) consistency with the use of invalidation or update reports. The server periodically broadcasts update or invalidation messages to clients. Update reports reflect the changes in the state of the database. A drawback of the method is that invalidation messages impose a high processing load on clients. Clients have to listen to all reports, even though there may be no changes to the data they cache. In this paper we describe a flexible cache consistency maintenance protocol for mobile distributed systems, which consists of two parts. First, we propose a notification protocol that caters for various consistency requirements. Clients can specify different attributes, such as granularity of data, time intervals and predicates, of the update messages they are interested in. This protocol is responsible for propagating and maintaining this client specific information. Second, we employ shared time-locks, namely strict read/write locks and permissive read/write locks to maintain data consistency. All these locks have pre-assigned time limits, after which they expire. Strict and permissive read locks on the same data item are shareable between clients, whereas strict write locks and permissive write locks (called ownership server locks) are exclusive write locks that can only be held by one client. The difference between ownership write locks and strict write locks is in the way the result of the write operation is propagated. Ownership server locks have Writes propagated to the server immediately, effectively implementing write-through caching. Strict write

Proceedings of the Ninth International Conference on Parallel and Distributed Systems (ICPADS’02) 1521-9097/02 $17.00 © 2002 IEEE

locks have writes applied to data locally and updates are flushed to the server at commit time. When evaluating operation efficiency, or its counterpart inefficiency measured by the number of operations rejected as they would lead to inconsistent data, we detected a noticeably better performance of the weak consistency protocol over the strict consistency protocol in every case. With increasing read-write sharing the performance improvement was becoming larger, e.g. in case of 3/4th overlapping readwrite operations the weak protocol rejected only half as many operations as the strict protocol did. Several technical aspects of our approach are not detailed here. More details are provided in [6]. Section 2 of this paper describes the notification protocol that defines the semantics of the client-server communication and is responsible for propagating updates to clients. Strong and weak data consistency is defined and the strong and weak consistency protocols are explained in Section 3. Strict and permissive locks are also introduced, as well as their usage with the strict and weak consistency protocols. Section 4 presents the performance results. Section 5 discusses the results and section 6 concludes the paper.

2 Notification Protocol The protocol has two types of messages: notification requests and update notifications. After a short introduction a description of the two message types is presented in this section. A server manages data and access to that data on behalf of clients. The clients can cache replicas of data and work remotely on cached data. Multiple clients can cache the same data item, and the server needs to provide a concurrent access control scheme to ensure the consistency of the cached replicas. The concurrency control method implemented here is based on time locks that the clients need to obtain from the server before they can work on locally cached data. In the proposed protocol different clients can have different consistency requirements for the same data item, and a client can have different consistency requirements for different data items cached locally. The actual consistency requirements can vary from strong to weak consistency, with intermediate levels also available.

2.1 Notification Request In case of a cache miss, i.e. when the requested data item is not available locally, the client retrieves the data from the server and puts it in the local cache as usual. However, the client cannot start to use the data until it acquires an appropriate lock on that data item. After a lock having been granted the client can analyse the data and send a notification request indicating its consistency requirements for that data item to the server.

The notification request message is a tuple of the form

(X : T; fa1; a2; : : : ; ang; P _ Q; T ) where T is a type and X is an object of T ; a1 ,a2 ,. . . ,an are attributes of X ; is the set of all possible attributes, that is ai 2 [ fAN Y g; X is the set of all events over X , where fANYg X ; P and Q are predicate, where P X , Q X . Each of them is in the form of S1 ^ S2 ^ ... ^ Sn ; and T is a time interval specified in seconds. X ai is a pair that uniquely identifies an object and one of its data members. ai can have the special value of ANY, which represents all data members of object X. P and Q are predicates, which when false would trigger the server to send an update notification message. P can have the special value of ANY, which signifies any change to dataitem. T represents the maximum delay from the time an update of X ai pair is registered until the relevant update message generation/reception, which a client can tolerate. A value of zero signals an immediate update requirement and a value of s indicates that the client can put up with at most s second notification delay. In addition to setting the degree of consistency, the allowed maximum delay can also be used to improve performance by reducing communication costs, as the server can combine several updates to clients into a single message. E.g. if there is an outstanding message for client C which needs to be delivered in 10 seconds, and another update is processed which requires a message to be delivered to C immediately, the two updates can be sent together.

:

:

:

Example 1 An NR message of the form (X Account; balance; age ; balance > age < ; ), where X is an object with attributes balance and age, where (balance > 200 age < 45) is the predicate which

g(

f

200 ^

45 0

^

when false would trigger an update notification message. The above message denotes strong consistency for the attributes balance and age of X due to the value of T field being 0. The above example shows fine granularity consistency requirements. An example of coarse granularity is a notification message of the form (X Account; fAN Y g; AN Y; ) that implies strong consistency at the entire object level.

:

0

2.2 Update Notification Updates that are committed on the server are propagated to every client that (i) has cached a copy of the data item being updated, (ii) has registered a notification request for the given data item and (iii) the condition for update messages is met. The update notification messages are broadcast to clients. Figure 1 depicts an update notification message. The message is of the form:

:

(X T; fa1 ; a2 ; : : : ; an g; fc1 ; c2 ; : : : ; cn g; T S )


where

is a type, X is an object of type T , n is a set of attributes for which updates are sent (along with the old values), and c1 ; c2 ; : : : ; cn is the corresponding set of new values for the above attributes. T

a1 ; a2 ; : : : ; a

Client 2

Client 1

Client Q

Server sends Update Notification Message UN (X:Account, {age:15}, {age:17}, TS)

C1 updates "age" (age = age + 2)

check

Server

NR1 (X:Account, {age}, age > 20,0) NR2 (X:Account, {age}, ANY, 0) ... ... ... NRn(X:Account, {Age}, age < 18, 200) Notification Table

Figure 1. Client-Server Communication – Strict Locks TS is the timestamp indicating when the update was accepted at the server. Clients can examine the TS value and check un-committed operations on the cached data to see whether there were any conflicting operations that need to be rolled-back by the client, such as local updates bearing timestamps larger than the timestamp of the update received from the server and using earlier values. Consistency requirements determine the amount of messaging performed by the server. Strict consistency requirements, i.e. immediate notification requests represent disproportionally higher load, because weaker consistency requirements allow grouping of several updates into one message. The server can use a Dependency Table [1] for data and clients to determine which clients are affected by an update and who needs to be notified of the changes.

3 Consistency This section describes the time-lock concept and is followed by the lock-semantics and consistency protocols.

3.1 Locks A lock is an operation that, when applied on a data item, ensures and guarantees access to the data item. Locks are used to provide concurrent access to data in a consistent manner when several clients are accessing the same data item simultaneously. Locking in mobile systems is different from locking in database systems, as the unreliability of mobile communication links and the fact that clients can get disconnected for intermittent periods need to be taken

into account. In the following a description of the proposed time-locks for mobile environments is given. (A) Strict Read Locks (SRLs) An SRL is a variation of a traditional read lock. Multiple SRLs can exist on the same data item at any one time. Before performing a write operation, the client needs to upgrade the SRL to a strict write lock (SWL). By obtaining an SRL, a client receives a guarantee that no other clients will modify that data item. When there is more than one SRL on data item x and a client requests the SRL to be upgraded to an SWL, all existing SRLs need to be revoked before the SWL can be granted. This provides clients with read only access to the data on one hand, and maintains strict consistency when data is being written on the other. The SRL will be granted for a period of t, which is calculated from what the client requested and what the server can afford. The client can renew the SRL or upgrade it to an SWL before the period t ends. After expiry the lock is reclaimed . (B) Strict Write Locks (SWL) SWL is a variation of a traditional write lock. An SWL is granted for a period determined by the server from the request and from other factors, such as how many other clients have locks on the data item. Only one client can hold an SWL on a data item at a time. Once a client gives up an SWL, or when it expires, the server sends an update notification (UN) message to all clients who have a cached a copy of the given data item. The update notification message contains the committed changes for the data item. While all clients can keep replicas for a data item x, when x is locked with an SWL the clients are not allowed to read or modify the replicas. They can work with it only after having been granted an appropriate lock by the server. Clients holding an SWL can work with a local copy and propagate the changes back to the server when processing has been completed, provided the lock has not expired. These locks are very useful when a client has high consistency requirements or would like to work off-line. (C) Permissive Read Locks (PRL) PRL is a shared read lock that can be held by multiple clients. A PRL is granted for a period t after which it expires. On gaining a PRL, a client gets read access to the data item (i.e. they can read it from the local cache), while other clients may also have access to the same data item simultaneously. Clients can renew a PRL or upgrade it to an SRL, SWL or OSL (Ownership Server Lock) when it expires or when a client wants to update the data respectively. Clients are informed of any updates performed on the data while they hold a PRL. If a client reads a value of a data item and subsequently an update was applied by someone else, the operations performed after the update need to be rolled back. PRLs can be held concurrently with any other lock


defined on the same data item. This ability makes PRLs the most flexible amongst the locks in our system. Even though PRLs improve concurrency, clients with PRLs could suffer from a high operation rollback ratio if they have read stale data.

(D) Ownership Server Locks (OSL) An ownership Server Lock is a shared write lock. Multiple clients can have PRLs on a data item x on which a client has an OSL. The client having the OSL employs write-through caching by writing any update directly to the server. The server notifies the other clients holding PRLs on x of the changes made to x. If a client with a PRL has read the old value of x, they need to rollback the operations involving the old value of x and start to work with the new value of x when they receive the update notification message. Clients having a PRL on x and wanting to update x need to upgrade the PRL to an OSL. A request for OSL is granted if no other OSL or strict lock exists on the data item in question. The communication has to be fairly stable for the good functioning of this lock, as clients with OSL need to update the primary copy on the server. If the communication is unreliable and has frequent disconnections, the abort rate of clients holding PRLs can become high. That is, an OSL is appropriate for clients with fairly stable link to the server and when clients can put up with relatively higher abort rate instead of higher availability. Table 1 summarises the compatibility for the locks SRL (Strict Read Locks), SWL (Strict Write Locks), PRL (Permissive Read Locks), and OSL (Ownership Server Locks). Based on these lock properties we can split the locks into the following two pair-types: strict pair (SRL and SWL), and permissive pair (PRL and OSL).

none PRL SRL SWL OSL

PRL Y Y Y Y Y

SRL Y Y Y N N

SWL Y Y N N N

OSL Y Y N N N

Table 1. Lock Compatibility Matrix Different consistency requirements (e.g. strong or/and weak ) can be satisfied by using the above lock-pairs in a mutually exclusive manner: the strict pair is used for providing strong consistency requirements, whereas the permissive pair is used for providing weak consistency requirements. When different clients have different consistency requirements for the same data, the above locks can interoperate as shown in the table above.

3.2 Consistency With the existence of multiple copies of data the task of maintaining consistency amongst them is important. It is critical for replicas to be in synchron with the primary copy (which resides on the server) as well as with other replicas. Consistency between these replicas can be maintained by using a scheme in which each update sent to the server is propagated by the server to the other replicas. Efficiency is an important consideration with any replicated data, including caching. The amount of messages to be sent is proportional to the number of replicas that exist for a data item at any time. In a scenario with a high number of write requests, the update notification conditions, i.e. the predicates and the time delay parameter, have to be selected carefully in order to maintain efficiency. This is usually easy to achieve, as not all clients are interested in each update immediately. A few clients might be interested in certain data items only and would like to be notified only if that value changes. Others might want to be notified only if the new value of the data item satisfies a certain predicate (e.g. Notify if x is greater than 10) or might not care about changes in certain data items at all. Another problem in mobile environments is that some clients might not be connected to the network, which further deteriorates communication efficiency by causing repeated retransmission attempts. 3.2.1 Strong Consistency Protocol A client has strong consistency requirements on a particular data item when it wants immediate notification about every update on that data item and would like all updates it makes to be final. Updates committed on the server are immediately propagated to all clients with strict consistency requirements. For example, a financial application making decisions based on the current balance of an account would immediately like to know of any changes in the balance. Similarly, if an application debits a sum against an account, the effect of this operation has to be final that cannot be rolled back. A client wanting to maintain strict consistency would use strict locks for the purpose. In case of a cache miss (client request for an operation on data that is not in the client cache) the client request is relayed to the server. The server returns a copy of the data item, and the client replies by specifying the granularity and type of its consistency requirements via the notification protocol. Strict Locks A client can request an SRL from the server on the data item it wants to read. Multiple clients can hold SRLs on the same data simultaneously. A client can request the strict read lock to be upgraded to a strict write lock when the client wishes


to make updates to the data. A request for a strict write lock is granted only if there are no other write locks on the data item. All read locks are revoked when a write lock is granted to a client: the notification protocol sends an invalidation message to all clients having a read lock on that data item. Example 2 As depicted in Figure 2, C1 and then C2 request SRLs on data item x. The SRLs are granted for the time periods t and u respectively. At the end of t, C1 requests an upgrade of the lock to an SWL. The SWL is granted, but before that the read lock of C2 is cancelled. (The server informs C2 via the notification protocol that its read lock has become invalid.) Just as the SWL was allocated to C1 , C3 sends a request for an SRL, which is rejected by the server. At the end of the period of the SWL, C1 propagates the changes it made on x back to the server. C2 is informed of the updates as it has a cached copy of x, but cannot work with x until it has obtained an appropriate lock. Read Lock cancelled SRL(x,t)

Update sent to Server

Server sends UN to all clients with copy of x

SWL(x,w)

C1

SRL(x,u) C2

SRL(x,v) C3

X (Rejected by Server)

Figure 2. Client-Server Communication – Strict Locks To reduce unnecessary data transfer, when a client’s SRL is invalidated, the client is not required to clear its cache, i.e. it can still keep the cached copy, but before reading or writing data it needs to obtain an appropriate lock from the server. When a client sends a requests for any lock to the server, the server checks and ensures that the client has correct data in its cache. If the cached data is not correct, the server piggybacks the new value on the message containing the lock. A client c holding a strict write lock on a data item x can disconnect from the server, work with the locally cached copy, reconnect before the lock expires and renew the lock or send the updates to the server and release the lock. The protocol guarantees that no other client would read or update x until the lock expires or c voluntarily releases the lock. When the SWL is released, the server sends update notifications to all clients holding a cached copy of x.

3.2.2 Weak Consistency Protocol Weak consistency is used when a client does not need up-todate data all the time. Update messages may be delayed or even omitted if the changes are considered to be insignificant or irrelevant; e.g. the client can inform the server that changes below a given threshold need not be communicated. A client using weakly consistent data, however, is susceptible to operation roll-backs as it may have missed an update and worked with stale data. It is the responsibility of the application to define the notification conditions properly and avoid using stale data. Permissive Locks The permissive pair of locks allows a client to hold read locks on data items that are locked by other clients for writing. Consistency is maintained by forcing the owner of the write lock to make write-through updates directly to the server. The server then propagates updates to clients that hold PRLs on the data item. Permissive locks are also time locks and the server allocates each permissive lock for a certain period of time after negotiating it with the requesting client. A client sends a request for a Permissive Read Lock (PRL) to the server when it wants to read a data item. Multiple clients can hold a PRL on the same data item at the same time. The server ensures that clients with a PRL would be informed of any changes to the data item on which they hold the lock. Assuming the client is connected, the maximum delay in propagating updates is the message latency from the server to the client. Before the PRL expires, a client can either renew the PRL or upgrade it to an Ownership Server Lock (OSL) in order for the client to retain the PRL or make updates to the data respectively. If the client fails to do either, the lock is reclaimed by the server, i.e. it expires. When a client requests a permissive read lock (PRL) from the server, it also nominates the length of time it needs the lock. The server may grant the lock for the full period or for part of it only, or the request may be rejected. If the PRL is granted, the server guarantees that all updates on the data item will be propagated to the client. The client can relax this by nominating conditions that need to be satisfied in order to receive an update, e.g. if the data is above a certain value, no updates are needed. The client can also specify a maximum notification delay (update latency) for the duration of the lock, in which case updates need not be sent immediately. Before expiry clients can request the renewal of a PRL, request the upgrading of the PRL to an ownership lock (OSL) in order to make updates, or release the lock if not needed any more. Upon expiry the server reclaims the lock. The Ownership Server Lock (OSL) is a write lock that forces the owner of the OSL to make write-through updates.


This allows the server to propagate changes to other clients holding a PRL on the updated item immediately. A client with an OSL cannot make changes to data while disconnected, as consistency guarantees could not be met: clients having PRLs on the data item could not be notified about the changes within a time limit.

Example 3 As depicted in Figure 3, C1 and C4 hold PRLs on data item x for time periods t and w respectively. C2 also acquires a PRL on x for a period of u. C1 ’s and C4 ’s PRL expires roughly at the same time. C4 lets the lock expire and does not do anything for a while, whereas C1 upgrades the PRL to an OSL. C3 requests a PRL on x while there are already a PRL and a OSL on x. The request is granted. At time j , C1 updates the value of x. According to the rules, this update operation immediately overwrites x at the server. The server multicasts an update notification (UN) message containing the update to C2 and C3 , as they hold PRLs on x. After C1 ’s OSL expires, C4 requests an OSL on x. On receiving this request, the server checks whether the copy of x cached at C4 is the most recent copy. It is not, C4 missed one update, so the server piggybacks the new value of x on the reply message granting the Ownership Server lock for time z .

UN message Server checks to replicas whether C4 has updated copy in the cache

C1 updates x PRL(x,t)

Server sends updated copy and grants the OSL

OSL(x,t)

C1

PRL(x,u) C2

4 Performance Results This section presents the simulation experiments and performance results. A client-server application was implemented in Java. The communication between clients and servers was using (Java) RMI. The implementation environment consisted of mostly diskless X-terminals connected to Sun SPARC machines running Sun Solaris 2.7. A 100 Mbps link connected each client machine to the backbone, the servers had Gbps connections to the network. The server provides a standard interface to clients and is accessible via Java RMI. It keeps the data on behalf of clients and each client access to data is mediated by the server. Appropriate locks need to be obtained by clients in order to operate on the data. The server provides the locking mechanism and contains a lock table and a cache table, which maintain information about the current locks and the replicas cached by different clients respectively. The server also maintains a notification table to keep information on notification requirements. A banking application designed to simulate a Mobile Funds Transfer System is implemented to test and benchmark the proposed approach. Clients can request account objects to cache for local and possibly off-line processing. They can read or update the object according to the lock held, throughout the duration of the lock. The list of tasks clients can perform includes transfer of funds between accounts, changing personal information on the account and check transactions. Figure 4 shows the number of successfully completed operations against a varying number of concurrent clients using the strict consistency protocol. Each curve represents a constant ratio of conflicting read-write operations. In conflicting operations there are multiple clients contending for the same data item. Figure 5 shows the results of the same measurements for the weak consistency protocol. 60

C3 Time j PRL(x,w)

OSL(x,z)

C3

Figure 3. Client-Server Communication – Permissive Locks

Number of Completed Operations

PRL(x,v)

40 No Overlapping read-write requests 1/4th Overlapping read-write requests 1/2 Overlapping read-write requests 3/4th Overlapping read-write requests 20

0

Clients using the permissive pair of locks need to have good connections and must stay connected for the duration of working with the cached data. If they fail to do so, operations may have to abort due to missed updates. Clients with less reliable connection or wanting to work off-line should use strict locks.

0

2

4

6

8

10

Number of Clients

Figure 4. Number of Operations Completed [Strict Consistency Protocol]


Number of Completed Operations

60

5 Conclusion

40 No Overlapping read-write requests 1/4th Overlapping read-write requests 1/2 Overlapping read-write requests 3/4th Overlapping read-write requests 20

0 0

2

4

6

8

10

Number of Clients

Figure 5. Number of Operations Completed [Weak Consistency Protocol]

Figures 4 and 5 indicate that the number of successfully completed operations decreases with the increase of the ratio of conflicting read-write operations to the total number of requested operations. The number of operations not completed is far greater when using the strict consistency protocol than it is when using the weak consistency protocol. In the extreme case, the weak consistency protocol’s completion rate is almost two and half times higher. Figure 6 presents the results of scalability testing. Multiple clients were run with a fixed number of requests from each client, and execution times were measured. As can be seen from the figure, if the number of operations is relatively low, the system performs well: by increasing the number of clients there is only a logarithmic increase in execution time. As the number of operations becomes larger, however, system scalability deteriorates and the increase in execution time gradually becomes exponential.

Acknowledgements. This work is supported by the Australian Research Council (ARC) Linkage-project grant no. LP0218853.

References [1] J. Challenger, A. Iyengar and P. Dantzig, “A Scalable System for Consistently Caching Dynamic Web Data”. Proc. of the 18th Annual Joint Conf. of the IEEE Computer and Communications Societies, 1999. [2] T. Imienlinski and B. R. Badrinath, “Wireless Mobile Computing: Challenges in Data Management”. Communication of the ACM, 37(10), 1994.

25000

20000

Time (Seconds)

In this paper we proposed a consistency protocol with update messages to improve the performance of caching in mobile environments. We introduced two types of consistency, weak and strong, and demonstrated that the weak consistency protocol, with a linear increase in messages over the number of writes, works reasonably well compared to the strong consistency protocol. It is also expected that the weak consistency protocol performs at least as well as other similar protocols discussed (e.g. 2PL, optimistic concurrency control, etc.). Thus it can be concluded that the weak consistency protocol is appropriate for clients with a relatively strong connection and who wish to work online. The notification protocol presented is used for propagating updates to clients, and for obtaining and maintaining client specific information. These include time interval within which updates need to be propagated to the client, predicates that when false would trigger an update message, etc. This paper clearly demonstrated that it is possible to support disconnected operations with reasonable degree of concurrency. A loose sharing method for data was shown which performed very well even under high read/read or read/write sharing.

2000 Operations Per Client 4000 Operations Per Client 6000 Operations Per Client 8000 Operations Per Client 10000 Operations Per Client

15000

10000

5000

0 0

2

4

6

8

10

Number of Concurrent Clients

Figure 6. System Throughput - varying number of operations per client

[3] S. Lee, C. Hwang and H. Yu, “Supporting Transactional Cache Consistency in Mobile Database Systems”. Proc. of MobiDE, Seattle, 1999, pp. 6-13. [4] E. Pitoura, B. Bhargava, “Data Consistency in Intermittently Connected Distributed Systems”. IEEE Transaction on Knowledge and Data Engineering, 11(6), 1998, pp. 896915. [5] R. Ramakrishnan and J. Gehrke, “Database Management Systems. (2nd Ed.)”. McGraw Hill, 1999. [6] A. Vora, Z. Tari and P. Bertok, “A Flexible Cache Consistency Protocol for Mobile Systems Using Shareable Read/Write Time Locks”. Technical report, RMIT University, School of Computer Science and Information Technology, July 2002.
