1 / 34

RPC, Events, Streams

RPC, Events, Streams. Three Ways to Interact. Synchronous -- RPC Asynchronous -- Events Streams -- a connected series of events. Remote Procedure Call. Target, eg “callee”, already published class or method published The “call” may be direct or indirect caller waits for return

ivory-chen
Download Presentation

RPC, Events, Streams

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. RPC, Events, Streams

  2. Three Ways to Interact • Synchronous -- RPC • Asynchronous -- Events • Streams -- a connected series of events

  3. Remote Procedure Call • Target, eg “callee”, already published • class or method published • The “call” may be direct or indirect • caller waits for return • Differences between systems: • how dynamic • communication mechanism

  4. Events • Callback procedure already published • method associated with event • The “call” is usually indirect • “caller” does not wait for return • Differences between systems • how dynamic • communication mechanism

  5. Event == RPC • An event causes an Remote Call • from event generator to callback • parameters are packed together into one parameter structure • event generator does not “care” about response • Why are there two different mechanisms?

  6. Event <> RPC • OS people write event generator code • What about “higher-level” events? • events that result from lower level events • e.g. average temperature, verbal command given • With events, callee makes association • with RPC, caller makes association • with Events, multiple calls/event • Perhaps they should be the same

  7. Streams • What is a stream? (popular) • Is it like an RPC or like Event? • Look more like events • Event gen. waits for return • Callee does other things during call • just worries about termination of stream • Parameter passing is like neither • Callee must publish beforehand

  8. Other major differences • Publish & Subscribe done at different places: OS, user code, other mechanism • OS code: supported multiple languages • Event types: mapped to some number • numbers treated the same at all levels of coding • Treatment is outgrowth of virtual world programming (non-pervasive) • Pervasive is different because of distributed nature of calls, events, and streams

  9. Historical Examination • Out-of-program calls -- OS functions • coded as calls, implemented as events (traps) • Micro-kernel: • treat OS as multi-tasking multi-treating system • separate functionality from policy • Streams -- (sequential file system access) • First everything explicit in code and JCL • Unix contribution: sequential file is common • Standard In, Out, Error • Specified at runtime (a.out < myInputFile)

  10. Comments on Common Case • Rule of thumb: • make common case efficient (eg. H/W) • provide (any kind of) support of others • 90 / 10 rule -- what is it? • 10% of files take up 90% of disk space • 90% of files take up 10% of disk space • actually, getting worse -- 95/5 rule • 90% of jobs do the same thing • but consume only 10% of resources • Uncommon cases are all different -- heavy tail

  11. Accessing streams • When stream is file-like • Either by programmer or user • within code: open(”/dev/cdrom”,”r”) • from shell: a.out < /dev/cdrom • When stream is network object • Either by programmer • from GUI/Browser click on link • from within code: very hidden, usually not stdin

  12. Pervasive Computing Case • Streaming source specified at runtime • Subscribe (eg Get handle) to cd-rom device • use some middleware mechanism (RPC, event, stream) • User specification • rarely provided -- everyone provides “automation” • bluetooth provides awkward mechanism (list pick) • In favor of automatic control, we have taken away power from user • In favor of wireless, we have taken away power from user

  13. Why wireless is good

  14. Honey, look at this cool thing I just got

  15. Some attempts at a solution • (other presentation) • (not yet integrated with previous)

  16. CORE: Communication Oriented Routing Environment (Oxygen Research Group)

  17. Assumptions • Actuators / Sensors (I/O) in the environment • Many are shared by apps & users • Many are flaky / faulty • “User” does not know much about them • Environment, application, users desires change over time

  18. An Oxygen Application • Interconnected Collection of Stuff • Who specifies the stuff? • I don’t know, but its mostly virtual stuff • Many layers of abstraction • “Don’t ask, its turtles all the way down” • Two main layers of programming • Professionals • Users, e.g. grandmother

  19. Communications-Oriented Programs • Connecting the (virtual) stuff done by user • Home stereo / theater analogy • Plug Stuff together; unplug it if doesn’t work • Don’t like it, unplug it • Device drivers, services, clients, don’t know to whom or to what they connect • In client/server model, • server knows a lot about the client, • the client knows even more about the server • Extend Unix Pipes

  20. Physical Devices Programs (Processes) App Larry Bear’s CORE App CORE CORE Other COREs Larry Bear

  21. Message Flow • Messages flow between nodes & core • Core is both language and router • Within Core Router, some messages • are interpreted and may trigger actions • other messages get routed to other nodes • Request-Reply message strategy • Even number of messages • No reply within time period, means error

  22. CORE Language Elements • Four elements • Nodes, • Links, • Messages, • Rules • Features • Interpreted Language • Statement is a message & reply • Each element has an inverse

  23. Presentation Speech Slide Speech Command Speech Nodehandler = (nickname, specifier) Nodes – Specify via INS Cam = [device=web-cam; location=518;…] PTRvision = [device=process; OS=Linux;File=Laser Vision, ..] CORE Laser Vision

  24. Node Statement Handler • When ‘node’ message arrives • Verified for correctness (statements allowed) • Routed to Node Manager (just another node) • Node Manager • INS lookup, verifies if allowed, creates if needed • Creates core thread to manage communication with node • Bookkeeping & reply message with handle/error

  25. Links Lcamera,vision = (Cam,PTRvision) Presentation Speech Slide Speech Command Speech CORE Laser Vision

  26. Link Statement Handler • Message routed to ‘link’ manager • Two queries to node mng for thread cntl • Message to thread controller of source node • Specifying destination thread controller • Message to thread controller of dest node • Specifying source thread controller • Bookkeeping & reply message handler/error

  27. Messages Messages flow over the links Next Slide! Presentation Speech Slide Speech Command Speech CORE Laser Vision

  28. Message Handling • Messages can be encrypted • Core statement messages have fixed format • Everything else is data message • Each node thread has two unbounded buffers • Core to node & Node to core • Logging, rollback, fault-tolerance

  29. Rules RULES: (trigger,action) ( MESSQuestion , Lslide,lcd-- & Lslide,qlcd ) Presentation Speech Slide Speech Questions Command Speech CORE Questions Questions Laser Vision

  30. Rule Statement Handler • ( trigger , consequence ) • Both are “event sets” • Eight basic events: • +Node, -Node, +Link, -Link • +Message, -Message, +Rule, -Rule • Event set is a set of events • Trigger is true when events are true • Consequence makes events true

  31. Rules – A link is a rule • A message event is of form • (node, message specifier) • ( message specifier , node ) • Message came from or going to node • A link (x,y) is just shorthand for the rule: • +( x , m )  ( - (x, m) , +(m , y) ) • If a message m arrives at node x, then make that event false (remove the message) andmake the event of m arriving at y from core true.

  32. Rules – Access Control Lists • An access control list is just a rule • When messages arrive at node, if they arrive from valid node, then allowed to continue to flow. • Modifying access control lists is just adding or removing rules.

  33. Rules • Rule statement gets sent to rule manager • Event set is just another shorthand for rules • Rule manager sends command to trigger node thread that tells it about the consequence • Rules are reversible

  34. Reversibility • Each statement is invertible (reversible) • If there is an error in the application specification, then can undo it all. • General debugging is possible with reversible rules and message flow

More Related