Contents   Index

The Model

I have decided that the implementation takes place at the C [21] interface level (e.g, replacing fopen and fclose), not at the UNIX system level (e.g., neither open nor close). This will make it possible to use the system on other platforms (assuming that the programmers use the C interface there). However it might result in even more overhead than has probably already been introduced by implementing the C interface on top of the UNIX primitives--you win some, you loose some. I have decided to do so anyway, simply because it eases the implementation.

I have already decided to do LRU-caching, see Section 3.6, but I have not yet decided whether the system should cache multiple copies of a file--i.e., if multiple processes on the client are using the file--or just one copy.

I have decided to cache just one copy.^5.1 If the user of the mobile client is using programs that access files concurrently (e.g., multiple instances of the same program), then he or she might end up with local conflicts--but it is probably the users own fault, since mobile computers are normally in use by a single person at a time, see Sections 1.2.1 and 2.3. Thus it is really no step back compared to what the users in a multi-user environment are faced with, because there the fault might as well be some other users.

This decision does, however, conflict with the traditional definition of session semantics [3]. My system guarantees session semantics pr. client and not pr. application.

Much of the presentation that follows is based on an article [51] presented at the OOPSLA'96 Workshop on Object Replication and Mobile Computing (ORMC'96).

Recall, that I am using a primary copy scheme with a single server and multiple clients using session semantics. The model is based on the use of time as a consistency measure. With each cached file is associated:

• A Modification Time ($MT_C$); the time of the last update to the file (on the server),
  • Note: From the subscript it is made clear that the replica resides on the client (as opposed to on the server).
• a Consistency Time ($CT$); the time at which the cached file was known to be consistent with the primary copy on the server, and
• a Consistency Check Time ($CCT$); the time of the last check for consistency between the cached file and the primary copy on the server.

If $CT=CCT$, then the last check for consistency was positive, otherwise negative. According to the definition of consistency, see Definition 3.4 in Section 3.3.5, a consistency check can be performed simply by comparing the modification time ($MT_C$) of the cached file with the modification time ($MT_S$) of the primary copy on the server.

With every open for reading must be associated a Consistency Time Bound ($CT \! B$), and with every open for writing must be associated a Modification Time Bound ($MT \! B$). Furthermore, an Expiration Time Bound ($ET \! B$) must be associated with each close. These time bounds must be given explicitly by the application. Their exact meanings are explained in Sections 5.1, 5.2 and 5.5, respectively.

Throughout the rest of this chapter the notations listed in Tables 5.1, 5.2, 5.3 will be used extensively; they will be explained later.

Table 5.1: Consistency times

$CT$	Consistency Time
$CCT$	Consistency Check Time
$C \! F$	Consistency Flag	$CT=CCT\Leftrightarrow$ $C \! F$
$MT$	(Server) Modification Time

Table 5.2: Expiration times

$ET$	Expiration Time
$RET$	Readlock Expiration Time
$W \! ET$	Writelock Expiration Time

Table 5.3: Time bounds

$CT \! B$	Consistency Time Bound
$MT \! B$	Modification Time Bound
$ET \! B$	Expiration Time Bound (*)
$RET \! B$	Readlock Expiration Time Bound
$W \! ET \! B$	Writelock Expiration Time Bound

(*): Referred to as Close Expiration Time ($CET$) in [51].

Footnotes

... copy.^5.1

This decision is new compared to the contents of [51].

  Contents   Index