CS514: Intermediate Course in Operating SystemsMobility is a huge topicFocus on a couple systems-level attemptsCharacteristics of mobilityRover goalsRover projectConclusion: Success!Two basic mechanismsRover operationsRover operationImportSlide 12InvokeExportSlide 15Slide 16Rover ArchitectureSlide 18Slide 19ImplementationApplicationsMail ReaderCalendarWeb browser proxySome thoughts on RoverSlide 26Surprising conclusionCoda File SystemDisconnected operation states on client (Venus)Conflict resolutionProblem with disconnected states approachWeak connectivity operation states on VenusIsolation-Only TransactionsState machine for IOTPending validationResolution StrategiesSome thoughts on CodaOther interesting workSlide 39CS514: Intermediate Course in Operating SystemsProfessor Ken BirmanVivek Vishnumurthy: TAMobility is a huge topicBreaks existing applicationsAnything bandwidth intensive or synchronousOpportunities for new applicationsLocation-specific (nearest Starbucks)Ubiquity (short messaging)Ad hoc networksCan’t possibly give it justice in one lectureFocus on a couple systems-level attemptsWhat can the system do to support applications in mobile contexts, and how how effective is it?Coda (mobile file system)CMU (AFS-based)Application awarenessRover (mobility systems toolkit)MITApplication transparentCharacteristics of mobilityDisconnection (long or short, predictable or sudden)Caching, hoarding, prefetching, DB/file inconsistenciesVariable and asymmetric bandwidthAbove, plus compression, prioritization, clever use of downlinkExpensive ($$$) BW Above, plus user controlBattery, battery, and batteryMinimize transmissions (and also processing)Weakened security (physical and radio)User auth, encryptionRover goalsPhilosophy is that applications know best how to deal with mobilityBut there are general mechanisms that all applications can benefit fromProvide a toolkit to applicationsMake it easier to write applications that deal with mobility issuesReduce client/server communications requirementsAllow the user to effectively work offline(Some slides care of Michael Ferguson)Rover projectBuild Rover toolkitBuild range of applications using Rover toolkitEmailCalendarBrowserEvaluate effectiveness of Rover for supporting these applicationsConclusion: Success!Though Rover itself has not taken off…Applications easy to portThey say…Performs wellCompared to what?In my mind, they never really answer the question whether a toolkit/OS approach is betterThis would be a hard question to answer…Two basic mechanismsRelocatable dynamic objects (RDO)Code/data shipping, like simple agents or process migrationAllows dynamic control over processing versus communications tradeoffQueued remote procedure calls (QRPC)Asynchronous RPCsAllows offline operations without blockingRover operationsImport objects onto client machineRDO: contains data and operations on the dataInvoke methods on those objectsExport logs of method invocations to serversCan also export RDOsReconcile client data with server dataRover operationImportImport call provides: Object ID (URN) Session ID callback routing argumentsImport call returns a “promise”Call is queued (QRPC) for lazy fetchImportWhen imported object arrives: Callback routine is called Object is put into the cache RDO may invoke a threadObject may be locked at serverInvokeApplication invokes methods on received object Each operation is stored Changes in object indicated by version vectorsExportExport call provides: Object ID (URN) Session ID callback routing argumentsExport call returns a “promise”Updates to object are labeled tentatively committedThe object operations are queued (QRPC)Non-FIFO delivery enables prioritizationExportThe server executes the operations, checks for conflictsApplications provide a conflict resolution routineExportRevolved operations are returned to the clientAfter callback, client marks objects as committedRover ArchitectureRover ArchitectureAll applications run over a single Rover processCommunicate via Local RPCAllows prioritization across applicationsRover ArchitectureNetwork scheduler can select TCP or SMTP (mail) for transportLatter for batching lower priority requests(Interim solution)ImplementationRDOs are Tcl/tk objectsTransported in HTTPUsing CERN’s Web Common LibraryServer uses CGI scriptsApplicationsMail reader (based on Exmh Tcl/Tk)Calendar (based on Ical Tcl/Tk calendar)Web browser proxy (new application)Mail ReaderParts of GUI and messages sent as RDOsRDOs used for prefetching and application-specific consistency (inconsistent folder changes)CalendarEach calendar item (appointment or notice) is an RDOItem imported, changed tentatively, and exported and committedRoutines for conflict resolutionError notice, or give some users priorityWeb browser proxyImplements “click ahead”During disconnection, clicks are queued for later downloadUser has access to list of queued clicksList is an RDODoes prefetchingSome thoughts on RoverRover is a nice proof-of-concept for how to deal with mobilityBut Rover itself of limited valueTcl/Tk based RDOs probably overtaken by JavaUse of SMTP a bad choice (they know this)Probably hard to automatically prioritize among disparate applicationsUser would prefer to control this based on immediate circumstancesNot clear there is much value to running Rover as a single, system serviceSome thoughts on RoverEmail not the best proof-of-concept applicationAlready fundamentally asynchronous, so not much different with RoverClick-ahead sounds like a bad idea to meI’d rather control when clicks happen…Calendar is a decent proof-of-concept applicationSurprising conclusionFrom the Rover paper:“The largest, most important, drawback of the Rover approach is that application designers must think carefully about how application functions should be divided between a client and a server”Funny…this struck me as probably the main advantage of Rover!!!Provides a nice model for how to think about disconnection, asynchrony, and consistencyCoda File SystemUnlike Rover, makes disconnection issues transparent to the application (and, to some extent, the user)Coda transparently propagates file modifications and handles
View Full Document