So far, we have seen systems designed for
for two forms of networks - the traditional strongly-connected networks in which disconnection of a computer is an exception, and rarely-connected networks in which the reverse is true. In the former, the exception occurs when a computer fails while in the latter it occurs when it replicates or merges its changes. Coda [,] is designed for hybrid networks in which a computer may be strongly-connected, rarely-connected, or weakly-connected, that is, connected to the network through an expensive low-bandwidth connection such as a cellular connection. Instead of creating local replicas, Coda creates a local cache of data. The semantics of file operations issued by the computer depends on its connection to the network.
When a computer is strongly-connected, it caches data accessed by it and immediately propagates the results of local operations to all other strongly-connected computers, which can refresh their local caches. Thus, if all computers are strongly-connected, strong immediate consistency is maintained among the caches. When a computer is disconnected in the rarely-connected mode, it allows the user to perform local operations on the cached data and propagates the results to other computers when it is next connects to the network. It cannot, however, provide access to data that are not cached. When it is weakly-connected, it loads the cache with data not stored in it, but does not immediately propagate changes to other computers to save on communication cost. It logs (and compresses) local changes and uses ''trickle re-integration'' to asynchronously send them in batch to the server. Moreover, it does not receive updates made by strongly-connected computers, thereby not impeding their progress. It receives remote changes when it is next strongly connected. (Why not receive them in trickle reintegration coming the other way?)
Coda has experimented with several approaches to merging cached and server copies of the file system. In an early version, it automatically merged certain kinds of changes. For instance, like Locus, it automatically merged concurrent insertions of new objects in a directory. For other changes, it required manual merging. For instance, if two users concurrently change the same file, it required them to manually merge the changes. However, this approach was too conservative when the users had changed independent parts of the file. some changes were automatically res
Therefore, Coda now allows a programmer to provide an application-specific program for merging versions of a file. For instance, a programmer of a calendar application can provide a program for merging concurrent operations to a calendar file based on the slots that were modified - if the slots are different then it combines the two changes, otherwise it makes an arbitrary choice or asks for user intervention. Thus, unlike Notes, Coda gives the application programmer control over how merging is done. Because of the large granularity of the data it manages (files/directories), there is more need for this feature in Coda.
Another difference is that it uses a more centralized approach for maintaining consistency. Data are stored in a (possibly replicated) server and caches of these data are stored in local clients. When a strongly-connected client invokes a file operation, it makes a call in the server to update the server copy of the file. The server, in turn, propagates the results in all strongly-connected clients by invoking callbacks in them. When a disconnected or weakly-connected wishes to integrate, its cache is merged with the server copy, and any updates to the server copy are transmitted to other strongly-connected clients through callbacks. Thus, clients do not do pairwise merging as in Notes - instead they merge with each other through the server(s). Replicated servers maintain consistency using another algorithm that assumes strong-connection among them.
Example: It is programmed as in the file case except that the programmer writes an application-specific merge procedure, which can, for instance, concatenate the conflicting strings, prefixing each string with the name of the user who entered it. The behavior of the application would be different in that it users would be able to use it in the disconnected and weakly connected modes. Of course, in the disconnected mode, they would not receive or transmit updates; while in the weakly-connected mode they would not receive updates, and local changes would be trickled asynchronously in batches to the strongly-connected users.