RPC Events Streams Three Ways to Interact Synchronous

RPC, Events, Streams

Three Ways to Interact Synchronous -- RPC Asynchronous -- Events Streams -- a connected series of events 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

Other major differences Publish & Subscribe done at different places: OS, user code, other mechanism OS code: supported multiple languages Event types: mapped to some 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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 < my. Input. File) 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

Why wireless is good 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

Honey, look at this cool thing I just got 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

Some attempts at a solution (other presentation) (not yet integrated with previous) 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

CORE: Communication Oriented Routing Environment (Oxygen Research Group) 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

CORE Physical Devices Programs (Processes) Other COREs App Larry Bear’s CORE Larry Bear App CORE 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

CORE Language Elements Four elements 1. Nodes, 2. Links, 3. Messages, 4. Rules Features Interpreted Language Statement is a message & reply Each element has an inverse 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

Node handler = (nickname, specifier) Nodes – Specify via INS Cam = [device=web-cam; location=518; …] PTRvision = [device=process; OS=Linux; File=Laser Vision, . . ] Presentation Speech Slide Speech Command Speech CORE Laser Vision 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

Links Lcamera, vision = (Cam, PTRvision) Presentation Speech Slide Speech Command Speech CORE Laser Vision 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

Messages flow over the links Next Slide! Presentation Speech Slide Speech Command Speech CORE Laser Vision 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

Rules RULES: (trigger, action) ( MESSQuestion , Lslide, lcd -- & Lslide, qlcd ) Presentation Speech. Questions Slide Speech Command Speech Questions CORE Questions Laser Vision 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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) and make the event of m arriving at y from core true. 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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. 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 6. 893 Spring 2004: RPC, Events, Streams Larry Rudolph