RPC, Events, Streams

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