rpc, events, streams. 6.893 spring 2004: rpc, events, streams larry rudolph three ways to interact...

RPC, Events, Streams

6.893 Spring 2004: RPC, Events, Streams Larry Rudolph

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 indirectcaller waits for return

Differences between systems:how dynamic

communication mechanism


Events

Callback procedure already published

method associated with event

The “call” is usually indirect“caller” does not wait for return

Differences between systemshow dynamic

communication mechanism


Event == RPC

An event causes an Remote Callfrom 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?


Event <> RPC

OS people write event generator codeWhat about “higher-level” events?

events that result from lower level events

e.g. average temperature, verbal command given

With events, callee makes associationwith RPC, caller makes association

with Events, multiple calls/event

Perhaps they should be the same


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 calljust worries about termination of stream

Parameter passing is like neither

Callee must publish beforehand


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


Historical Examination

Out-of-program calls -- OS functionscoded 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)


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


Accessing streams

When stream is file-likeEither by programmer or user

within code: open(”/dev/cdrom”,”r”)

from shell: a.out < /dev/cdrom

When stream is network objectEither by programmer

from GUI/Browser click on link

from within code: very hidden, usually not stdin


Pervasive Computing Case

Streaming source specified at runtimeSubscribe (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


Why wireless is good


Honey, look at this cool thing I just got


Some attempts at a solution

(other presentation)

(not yet integrated with previous)


CORE: Communication Oriented

Routing Environment

(Oxygen Research Group)


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


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 programmingProfessionals

Users, e.g. grandmother


Communications-Oriented Programs

Connecting the (virtual) stuff done by userHome 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


CORE

Larry Bear’sCORE

Physical Devices

App

App

Programs (Processes)

Larry Bear CORE

Other COREs


Message Flow

Messages flow between nodes & coreCore is both language and router

Within Core Router, some messagesare interpreted and may trigger actions

other messages get routed to other nodes

Request-Reply message strategyEven number of messages

No reply within time period, means error


CORE Language Elements

Four elements1. Nodes,

2. Links,

3. Messages,

4. Rules

FeaturesInterpreted Language

Statement is a message & reply

Each element has an inverse


Nodes – Specify via INS

CORE

Cam = [device=web-cam; location=518;…]

PTRvision = [device=process; OS=Linux;File=Laser Vision, ..]Slide

SpeechPresentation

Speech

CommandSpeech

LaserVision

Nodehandler = (nickname, specifier)


Node Statement Handler

When ‘node’ message arrivesVerified for correctness (statements allowed)

Routed to Node Manager (just another node)

Node ManagerINS lookup, verifies if allowed, creates if needed

Creates core thread to manage communication with node

Bookkeeping & reply message with handle/error


CORE

SlideSpeech

PresentationSpeech

CommandSpeech

LaserVision

Lcamera,vision = (Cam,PTRvision)

Links


Link Statement Handler

Message routed to ‘link’ manager

Two queries to node mng for thread cntl

Message to thread controller of source nodeSpecifying destination thread controller

Message to thread controller of dest nodeSpecifying source thread controller

Bookkeeping & reply message handler/error


CORE

SlideSpeech

PresentationSpeech

CommandSpeech

LaserVision

Messages flow over the links

Next Slide!

Messages


Message Handling

Messages can be encrypted

Core statement messages have fixed format

Everything else is data message

Each node thread has two unbounded buffersCore to node & Node to core

Logging, rollback, fault-tolerance


CORE

SlideSpeech

PresentationSpeech

CommandSpeech

LaserVision

RULES: (trigger,action)

Questions

( MESSQuestion , Lslide,lcd -- & Lslide,qlcd )

Rules

Questions

Questions


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


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.


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.


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


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

rpc, events, streams. 6.893 spring 2004: rpc, events, streams larry rudolph three ways to interact...

Documents