Occasionally Connected Computing¶
A data-work arrangement that preserves local reads and writes through intermittent remote reachability, then exchanges and reconciles changes.
Core Idea¶
Occasionally connected computing is an arrangement for data work when remote shared state is reachable only intermittently. A client or locally reachable replica can read and change data available to it without waiting for continuous remote contact. The arrangement retains local changes and later exchanges and reconciles them with other work when communication permits. Local usefulness is bounded by what is available locally; it does not imply that every requested item can be opened or every conflict resolved automatically.[1][2]
Kistler and Satyanarayanan's Coda file system and Terry and colleagues' Bayou storage system demonstrate unlike carriers of the same role pattern. Coda relies on a client disk cache when its shared file servers are unreachable, then validates and reintegrates logged changes. Bayou lets applications read and write through any accessible replica and spreads updates through occasional pairwise communication. The first has a recognizable disconnected mode; the second expressly allows degrees of connectedness. A single authoritative server, a binary link-state switch and one upload-then-download order are therefore not part of the common identity.[1][2]
Structural Signature¶
Signature: relation to remote shared data → locally reachable data and operations → useful reads and writes during intermittent remote reachability → retained local changes → later exchange and reconciliation under a disclosed conflict policy.[1][2]
- Remote shared relation. The local work is meant to rejoin a larger shared dataset or collaborative service. A permanently isolated standalone program with no exchange path is outside this arrangement.[1][2]
- Locally reachable work state. A cache or accessible replica supplies data and operations while some remote state cannot be reached. Coda serves cached files but reports misses as failures; Bayou can work against one reachable replica. Neither supports arbitrary uncached work.[1][2]
- Intermittent reachability. Contact may be absent or partial and later return. Coda switches modes when its accessible server set is empty; Bayou assumes only occasional pairwise contact, with no system-wide disconnected switch.[1][2]
- Retained mutations. Locally accepted work must remain available for later exchange. Coda logs offline file mutations; Bayou's writes can remain tentative at replicas.[1][2]
- Later exchange and reconciliation. Changes are propagated and divergence is handled under the system's rules. Coda validates replay on reintegration and can require repair; Bayou uses pairwise anti-entropy and application-supplied dependency checks and merge procedures. Those mechanisms differ, but omitting any later reconciliation leaves an unrelated fork.[1][2]
What It Is Not¶
A read-only offline page or cache with no retained local change path can improve viewing availability, but it does not meet this entry's read/write and later reconciliation scope. This is an editorial boundary for the admitted arrangement, not a theorem of either original paper. An online-only client that blocks every useful operation until its remote service responds likewise lacks the locally workable interval.[1][2]
The arrangement is not synonymous with Bayou's eventual-consistency guarantee. Bayou seeks eventual agreement with its own propagation, ordering and rollback machinery; Coda's file replay can encounter conflicts requiring user repair. Nor does local work promise total availability: Coda explicitly fails on cache misses during disconnection, and Bayou requires access to at least one replica for its described work.[1][2]
Scope of Application¶
Coda is a shared Unix file system with a client cache and remote servers. Its disconnected operation begins when the client cannot reach a server for the relevant volume. The client can continue work on cached files, records mutations in a persistent local log and, after contact returns, validates/replays them during reintegration. Conflicts can abort that process and require repair; Coda does not turn inaccessible uncached files into available ones. The paper also describes voluntary disconnection of a portable computer, so a fault is not a required trigger.[1]
Bayou is a weakly consistent replicated storage system for collaborative applications. A client can read and write through any accessible server replica; one may run on the same portable host. Servers exchange writes pairwise when they can communicate. The authors use a room-reservation scheduler and bibliographic database to show tentative, possibly conflicting work. Dependency checks and client-supplied merge procedures are Bayou's conflict machinery, while anti-entropy and ordering seek eventual agreement under its design assumptions. Those guarantees belong to Bayou, not automatically to every occasionally connected system.[2]
Clarity¶
The diagnostic question is whether useful data work can proceed while some remote shared state is unreachable and whether the locally accepted changes have a later integration path. It must specify which data remain local, which operations are permitted, what may fail, how updates are exchanged and what happens when edits conflict. “Works offline” alone leaves those questions unanswered.[1][2]
Coda and Bayou also clarify two uses of “local.” A Coda client has a partial, lower-quality cache contingent on a shared repository. Bayou's accessible server holds a replica of a collection and can accept writes for its clients. Both offer a locally reachable work state, but equating cache and full replica would erase their different data coverage and consistency claims.[1][2]
Manages Complexity¶
The arrangement separates availability of work from freshness and settlement of shared state. Coda's cached work may be useful while server contact is absent, yet a cache miss fails and a later replay may conflict. Bayou shows tentative reservations to users, rather than pretending each local acceptance is final. These examples make the status of local work explicit without requiring one universal consistency policy.[1][2]
It also separates connection pattern from work semantics. Bayou's peers need only occasional pairwise contact; no moment of global reconnection is required. Coda uses a client/server transition for a specific file system. The common abstraction is the deferred exchange and reconciliation of local changes, not one wiring diagram.[1][2]
Abstract Reasoning¶
Imagine a client with a cached file that it edits while Coda servers are unreachable. If the file was cached, the local edit can be logged; if it was not cached, the open can fail. When a server returns, the log can be validated and replayed, or the edit may need repair because another change conflicts. The ability to work locally therefore does not entail global acceptance of every local result.[1]
Now replace the client cache with a Bayou replica carrying a room schedule. A user may enter a tentative reservation even if other replicas are unreachable. Later pairwise exchange may reveal another reservation, and the application's checks and merge procedure decide what happens. The invariant across cases is local useful work followed by exchange and reconciliation; server authority, binary mode, data coverage and conflict algorithm change.[2]
Knowledge Transfer¶
For an intermittently reachable data service, ask five design questions in order: what shared state is at issue, what state and operations remain locally reachable, how accepted changes are retained, when/how peers exchange them and how divergent changes are exposed or reconciled. This role checklist can guide analysis beyond the two papers, but each new implementation needs its own evidence before claiming a particular availability or consistency guarantee.[1][2]
Do not transfer Coda's whole-file cache or Bayou's primary-commit and anti-entropy behavior as if they were universal. The transferable reasoning is the separation of continued local work from eventual shared settlement. Whether a system provides partial files, replicas, automatic merge or manual repair must be determined from its own contract.[1][2]
Examples¶
Coda portable client. The shared repository is a set of remote Unix file servers. Venus's disk cache holds previously obtained files and mappings. During voluntary detachment or a server/network interruption, requests for cached files can be served and file mutations logged; cache misses fail. On recovery, Venus validates and reintegrates the local mutation log, while conflicts can require a user to intervene. The client/server architecture and whole-file caching are Coda-specific.[1]
Bayou room scheduling. Shared room reservations are replicated among servers. A client can use an accessible replica when other servers cannot be contacted and can enter a tentative reservation. Pairwise anti-entropy later carries writes between replicas; dependency checks and application-provided merge logic address competing bookings. The system displays tentative status because a local reservation may later move or be rejected. This is a collaborative application on weak replicas, unlike Coda's file cache.[2]
Bayou bibliography. A portable user can add an entry to a locally reachable database copy without maintaining continuous contact. When replicas exchange changes, duplicate or competing keys may need resolution; a tentative key can change on commit. This is a second Bayou application, not an independent system proof of a universal merge guarantee.[2]
Structural Tensions¶
The papers expose setting-specific pressures without establishing one unavoidable quantitative trade-off for all occasionally connected computing. Coda's cache improves disconnected availability but covers only stored files and can need repair. Bayou favors read/write availability through weakly consistent replicas and exposes tentative results while its own convergence machinery works. The failure mode is to treat locally accepted work as globally final or to hide the gaps in cached data.[1][2]
No universal theorem here says that stronger offline availability must always produce a fixed amount of conflict or that every conflict has an automatic merge. The suitable conflict policy and user-visible state depend on the data and application.[1][2]
Structural–Framed Character¶
Vocabulary travel: “offline,” “disconnected” and “sync” cover both cases loosely, but Coda's mode and Bayou's degrees of connectivity differ. Evaluative weight: useful local work and acceptable conflict outcomes are application judgments; the role structure alone does not promise correctness or availability for every item. Institutional origin: the concept arose in concrete distributed-file and replicated-application designs, without one institution defining a mandatory protocol.[1][2]
Human-practice dependence: designers choose cached data, accepted operations, visibility of tentative work and conflict rules; users may also have to repair failed reintegration. Import versus recognition: recognize the arrangement only when local read/write capability and later integration are evidenced; merely labeling a static cache “offline-first” imports a broader name without the admitted change path. Its character: a portable structure of local data work plus deferred reconciliation, framed by each system's data and consistency contract.[1][2]
Structural Core vs. Domain Accent¶
The core is a relation to remote shared state, locally reachable useful data operations through intermittent contact, retained changes and later exchange/reconciliation. Coda's Venus cache, replay log, client/server mode and manual repair are one implementation. Bayou's full replicas, tentative writes, dependency checks, merge procedures, anti-entropy and primary commit are another. Remove one accent and the arrangement can remain; remove local work or the later exchange path and it does not.[1][2]
The common core remains an engineered data-work arrangement. A broader Prime would require independent transfer beyond these distributed-computing carriers and an all-instance role audit; the two papers alone do not establish that promotion. The zero-edge placement is therefore a reviewed specialist root, not an assertion that related graph, replica or consistency concepts are irrelevant.[1][2]
Instantiates / Related Primes¶
- No broader abstraction yet. Occasionally Connected Computing has no broader abstraction in the encyclopedia yet.
- Fault Tolerance — related, not broader. Coda can respond to failures, but planned detachment also qualifies; Fault Tolerance as the encyclopedia defines it needs a fault model, acceptable service bound, redundancy/recovery and quantified tolerance not required here.
- Network — substrate, not broader. Links connect machines, but Network studies the structure of connections itself as the explanatory object. Neither case requires that analytical identity to qualify.
- Eventual Consistency — Bayou-specific relation. Bayou seeks convergence under its update propagation and ordering assumptions; it is not a generic guarantee of Coda-style reintegration.
- Replica, Distributed Data Store and Peer-to-Peer Architecture — neighbors. Bayou uses replicas and pairwise exchange; Coda can instead use a partial client cache against servers. None of them, fully defined, is broader than every case of the arrangement.
- Synchronization — a distinct abstraction. Its phase/time alignment identity is not the same as deferred reconciliation of shared data.
Neighborhood in Abstraction Space¶
Occasionally Connected Computing sits in a sparse region of the domain-specific corpus (97th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Digital Resource Formats & Metadata (7 abstractions)
Nearest neighbors
- Format Relation — 0.78
- Second Normal Form — 0.78
- No-Force Policy — 0.76
- Distributed lock manager — 0.76
- Goal Modeling — 0.76
Computed from structural-signature embeddings · 2026-10-08
Not to Be Confused With¶
The entry is not a guarantee that a request succeeds without connectivity, that accepted local writes are already final everywhere, that a central authority exists, or that connection state has only two values. A read-only static cache without a deferred local change path is outside this admitted read/write scope. Bayou's anti-entropy and application merge machinery are one way of satisfying later exchange and conflict handling; Coda's replay/repair is another.[1][2]
References¶
[1] James J. Kistler and M. Satyanarayanan, “Disconnected Operation in the Coda File System”, ACM Transactions on Computer Systems 10(1), 1992, pp. 3–25. DOI: 10.1145/121132.121166. Original full paper, especially §2 and §§4.4–4.5. The cached-file limitation, local replay log, reintegration and possible conflict repair are directly described there. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v ↩w ↩x ↩y ↩z
[2] Douglas B. Terry, Marvin M. Theimer, Karin Petersen, Alan J. Demers, Mike J. Spreitzer and Carl H. Hauser, “Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System”, ACM SIGOPS Operating Systems Review 29(5), 1995, pp. 172–182. DOI: 10.1145/224057.224070. Original full paper, especially Abstract, §§1–5; §2 describes the room scheduler and bibliographic database, and §5 covers anti-entropy and eventual agreement under Bayou's design. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v ↩w ↩x ↩y ↩z ↩27