Chapter: Distributed Systems : Communication in Distributed System
Remote Procedure Call
Remote Procedure Call
– client:
"stub" instead of "proxy" (same function, different names)
o
local call, marshal arguments, communicate the
request
– •server:
o
dispatcher
o
"stub": unmarshal arguments, communicate
the results back
Role of client and server stub procedures in RPC in
the context of a procedural language
Case Study: Sun RPC
– •Sun RPC:
client-server in the SUN NFS (network file system)
o
UDP or TCP; in other unix OS as well
o
Also called ONC (Open Network Computing) RPC
– •Interface
Definition Language (IDL)
o
initially XDR is for data representation, extended
to be IDL
o
less modern than CORBA IDL and Java
– program
numbers instead of interface names
– procedure
numbers instead of procedure names
– single
input parameter (structs)
o
rpcgen: compiler for XDR
o
client stub; server main procedure, dispatcher, and
server stub
– XDR
marshalling, unmarshaling
– •Binding
(registry) via a local binder - portmapper
o
Server registers its program/version/port numbers
with portmapper
o
Client contacts the portmapper at a fixed port with
program/version numbers to get the server port
o
Different instances of the same service can be run
on different computers at different ports
– •Authentication
o
request and reply have additional fields
o
unix style (uid, gid), shared key for signing,
Kerberos
Events and Notifications
– •Idea
behind the use of events
o
One object can react to a change occurring in
another object
– •Events
o
Notifications of events: objects that represent
events
o
asynchronous and determined by receivers what
events are interested
o
event types
o
each type has attributes (information in it)
o
subscription filtering: focus on certain values in
the attributes (e.g. "buy" events, but only "buy car"
events)
– •Publish-subscribe
paradigm
– publish
events to send
– subscribe
events to receive
– •Main
characteristics in distributed event-based systems
o
Heterogeneous: a way to standardize communication
in heterogeneous systems
– not
designed to communicate directly
o
Asynchronous: notifications are sent asynchronously
– no need
for a publisher to wait for each subscriber--subscribers come and go
Dealing room system: allow dealers using computers
to see the latest information about the market prices of the stocks they deal
in
Distributed Event Notification
– Distributed
event notification
o
decouple publishers from subscribers via an event
service (manager)
– Architecture:
roles of participating objects
o
object of interest (usually changes in states are
interesting)
o
event
o
notification
o
subscriber
o
observer object (proxy) [reduce work on the object
of interest]
– •forwarding
– filtering
of events types and content/attributes
– patterns
of events (occurrence of multiple events, not just one)
– mailboxes
(notifications in batch es, subscriber might not be ready)
o
publisher (object of interest or observer object)
– generates
event notifications
Example: Distributed Event Notification
– •Three
cases
o
Inside object without an observer: send
notifications directly to the subscribers
o
Inside object with an observer: send notification
via the observer to the subscribers
o
Outside object (with an observer)
o
An observer queries the object of interest in order
to discover when events occur
o
The observer sends notifications to the subscribers
Case Study: Jini Distributed Event Specification
– –Allow a
potential subscriber in one Java Virtual Machine (JVM) to subscribe to and
receive notifications of events in an objectof interest in another JVM
– Main
objects
– event
generators (publishers)
– remote
event listeners (subscribers)
– remote
events (events)
– third-party
agents (observers)
– An object
subscribes to events by informing the event generator about the type of event
and specifying a remote event listener as the target for notification
Related Topics