ConclusionsFormulated the need & requirementsDesigned an infrastructure & applicationShown performance numbersThis was not easyJVMs underdevelopedPilot debugging infrastructure non-existentActiveProxy is still under developmentScalable yet versatile shared object system is complicated
Well be talking about the work weve done this semester on Object Sharing Over Mobile Devices.
Ill talk about our motivations for this work and the infrastructure that we built.
Yannis will then talk about a sample application we built on top of this infrastructure, our results and he will wrap up with conclusions. Almost everyone has a mobile device - be it a Palm Pilot or a Windows CE machine or a laptop. Pretty soon, all of these people will also have some form of Internet connection.
There is a need to run collaborative applications on these devices, such as distributed address books where changing your personal phone # will be automatically read by people who share your entry
being able to scribble on shared whiteboards or make red marks on a document that is being reviewed by a group of people
being able to read and modify code that a group of people are working on
and so on
Its hard to write such applications today because there is no shared data infrastructure for these mobile devices.We cant simply port an existing SW DSM because of the unique requirements of this design space.Firstly, the system has to be platform independentI need to be able to use this whether Im on a Palm device, a Windows CE device or a laptop.So it needs to be a SW solution, perhaps in Java where the interconnection is the Internet (because it is the only common network among these devices)The granularity of sharing should be user defined for optimal performance and ease of coding - thus it should be object based.The shared data should be stored on memory servers in the Internetthis scales w.r.t. both coherence communication and storage capacityMobile devices undergo periodic connectivity - they dont have a hard connection to the internet. Thus the system should allow life to go on if a device were to disconnect.And the system should be designed with an emphasis on low compute power, low bandwidth and high latency at the clients.So this is the system we designed to meet the requirements we just laid out.
One or more devices communicate with a memory server. Multiple memory servers can exist and they communicate by registering themselves with a memory service nameserver.
Each device communicates with its memory server through a cache that speaks the coherence protocol that was designed, which Ill explain in the next slide. Masqueraders can also exist in the network, which are programs that run on server machines performing compute intensive tasks but look just like a mobile device by communicating through a cache.
When a device asks to create a shared object, its memory server allocates space and returns an address. The device can register this address with an application nameserver under a name that is known to all the other devices. When another device requests a copy of this data, it sends its request to its memory server, which then finds the home memory server by decoding the address (perhaps looking up where the memory server is through the nameserver) and forwards the request to the home memory server and then sends back the result to the requesting device.This is the coherence protocol that the memory server runs. It is a directory based system (unlimited directory space).
It looks like your standard MSI protocol, but with some modifications. We wanted to allow both write through caches and write back caches, and in doing so, we optimized the write through cases to save coherence traffic and so added several more arcs in the protocol.
We also have 2 transition states to avoid long dependence chains, thus minimizing the risk of deadlock.
The system adheres to Sequential ConsistencyThere are no performance advantages of going to RC and so we didnt
The memory servers are multi threaded but array based locks are provided to serialize accesses to the same memory location. Remote read requests are serialized on each device because RMI calls are blocking.Here we have a screen shot of a MUD client that is running on a Xcopilot. We have tested the system with multiple memory servers and clients. We also have tested the system with real Palm 3s.
We also made some latency measurements on both Xcopilots & real Pilots.Please note that - the error is +/- 20msThe Palm3s were going through NT RAS and a slow serial linkThe ReadMiss rows indicate the latency seen at a mobile device at the application level in requesting a read of a shared object that is not present in the local cache but is present in valid form at the memory server. This latency includes the latency of having the cache check the device poll queue on its memory server (which is an RMI request from the mobile device to the iSpace manager running at a remote location in the network and having the iSpace manager spawn a thread which executes the poll queue method on the memory server and sending back the result along the same way).The ReadHit rows indicate the latency cost of having an application perform a read on a shared object that is present in the cache. This includes also the latency of checking the remote poll queue.The WriteThru rows indicate the latency cost of having an application perform a write on a shared object while using a write through cache which contains a copy of the object in shared state. This includes checking the remote poll queueThe WriteBack rows indicate the latency cost of having an application perform a write on a shared object while using a write back cache which contains a copy of the object in shared state. This includes checking the remote poll queue.