Designing a Replication System CS 188 Distributed Systems February 12, 2015

Introduction There are many situations in which we might use replicated data Let’s look at another, different one And design a system to work well in that situation

Challenging Network Environments Some environments have a hard time maintaining: low-loss low-latency End-to-end communications Examples: Mobile ad hoc networks Wireless sensor nets Situations where wireless connectivity to Internet is costly

Internet Protocols in These Environments Not what the Internet was designed for E.g., TCP Poor throughput if you get lots of losses or highly varying delays Basic architecture also a poor match: Packet switching End-to-end retransmission on loss

An Alternative: Delay Tolerant Networking A message switching approach Using store-and-forward at message level Designed to handle seriously changing conditions Like mobility changing which links are available Or long-term failures of network elements

Delay Tolerant Networking and Mobile Computing Essentially, use device mobility to establish new network links Those links allow access to devices not easily reachable before As devices move around, connectivity changes “Carry” messages on the mobile devices, in the hopes of finding ways to deliver them

Using Delay Tolerant Networking for Replication Use the delayed message delivery to handle update propagation Apply updates at one place and propagate them quickly, when possible When not, attach them to mobile devices Which may not hold replicas themselves Use device mobility to get updates to the other places they must go

A Specific Scenario A sensor network in a forest Sensors hold replicated files related to their task E.g., schedules of measurements Any copy updatable Some sensors can communicate with each other But most have no connectivity to the Internet, directly or indirectly Forest rangers carrying mobile devices periodically move through the forest But not specifically to visit sensors Occasionally coming into range of some sensor

Making Use of Mobility

Some Replication Constraints We want all replicas updatable We want to achieve the highest degree of consistency as fast as feasible We want to avoid conflicts, when possible And at least know when they happen Avoid requiring extra hardware Especially out in the woods

A Couple of Very Important Questions What is insufficiently specified about this scenario to allow good design? In particular, things that it’s reasonable to know Not oracular knowledge of the future Are there constraints we should put in place?

So, What’s Our Replication System Going To Be Like? Optimistic or conservative? Server oriented or peer oriented? Replicas only or caching? How will updates occur? How will updates be propagated? What is our replication granularity? How can we achieve fast consistency? How do we handle concurrency?

A Final Question Is file system replication even suitable here? Is there some other type of distributed data management we should use instead?