Object Sharing Over Mobile Devices

  • Published on
    13-Jan-2016

  • View
    29

  • Download
    11

Embed Size (px)

DESCRIPTION

Object Sharing Over Mobile Devices. Sharad Agarwal, Ioannis Mavroidis CS258. Alec Woo CS294-11. Vision Slide. An universal infrastructure where data can exist anywhere and be available to any device with some form of consistency guarantee. Server. Pilot. Pilot. Network. Server. Pilot. - PowerPoint PPT Presentation

Transcript

<ul><li><p>Object Sharing Over Mobile DevicesSharad Agarwal, Ioannis MavroidisCS258Alec WooCS294-11</p></li><li><p>Vision SlideAn universal infrastructure where data can exist anywhere and be available to any device with some form of consistency guaranteePilotLaptopToasterPilotPilotServerServerNetworkCamera</p></li><li><p>Why Share Over Mobile DevicesNeed collaborative applicationsnot for running Ocean or Barnes-Hutdistributed address bookgroup whiteboard / document reviewgroup codingcollaborative control of sensors and actuators</p><p>Need a shared data infrastructureCant simply port an existing SW DSM</p></li><li><p>Design RequirementsPlatform independentSW solution, in JavaInterconnection is the InternetObject based sharingData storage on remote serversscales {communication, capacity}available over disconnectionsAllows disconnected operationEmphasis on low compute power, low bandwidth, high latency tolerance</p></li><li><p>System ArchitecturePilotMasqueraderMemoryService NameserverInternetApp Nameserver</p></li><li><p>Coherence ProtocolDirectory basedSCreadwritethru / invupgr / invread / wr-invwritebackwritebackwritethrureadexreadex / invwritethru/invcreatedestroy</p></li><li><p>MUD ApplicationUsers control characters in an arena of roomsmove around, look, pick/drop objects, etcMasquerader creates shared objectsroom locks, room inventory, people in room, etcEach client requests character init from masqueraderWhen moving, linear lock ordering is used (Dining Philosophers)Automated bots that run around</p></li><li><p>ResultsLatency MeasurementsScreen Shot</p></li><li><p>ConclusionsFormulated the need &amp; requirementsDesigned an infrastructure &amp; applicationShown performance numbersThis was not easyJVMs underdevelopedPilot debugging infrastructure non-existentActiveProxy is still under developmentScalable yet versatile shared object system is complicated</p><p>Well be talking about the work weve done this semester on Object Sharing Over Mobile Devices.</p><p>Ill talk about our motivations for this work and the infrastructure that we built.</p><p>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.</p><p>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</p><p>being able to scribble on shared whiteboards or make red marks on a document that is being reviewed by a group of people</p><p>being able to read and modify code that a group of people are working on</p><p>and so on</p><p>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.</p><p>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.</p><p>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.</p><p>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).</p><p>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.</p><p>We also have 2 transition states to avoid long dependence chains, thus minimizing the risk of deadlock.</p><p>The system adheres to Sequential ConsistencyThere are no performance advantages of going to RC and so we didnt</p><p>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.</p><p>We also made some latency measurements on both Xcopilots &amp; 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.</p></li></ul>