1	Distributed Coordination-Based Systems
2	Need for Coordination so far we have mostly focused on request/response types of interactions between a client and a server means the client and server are tightly coupled client blocks until server delivers response what if the one of the parties crashes? what if more than two parties need to be involved? what if client and server are not executing at the same time? what if the server has asynchronous information to send to client? etc.
3	Introduction to Coordination Models A taxonomy of coordination models Where do Sockets/RPC/RMI fit?
4	Mailbox Model think e-mail: information is send to and stored in a (named) mailbox until retrieved mailboxes may be shared among processes (allows many-to-many communication)
5	Meeting Oriented Java event model allows for looser coupling between the client and the server the server, as an event source, does not explicitly know who is listening this is the basis of publish-subscribe Without such coupling, the client often has to keep polling the server TIB/Rendezvous: Messages transparent, applications deal with message semantics Messages are self-describing Processes are referentially uncoupled, communication is done based on subject-based addressing
6	Meeting Oriented The principle of a publish/subscribe system as implemented in TIB/Rendezvous.
7	Coordination Model (2) The overall architecture of a wide-area TIB/Rendezvous system: overlay network based on router daemons (multicast tree) Router daemons can be configured to filter incoming/outgoing subjects to improve scalability
8	Basic Messaging Attributes of a TIB/Rendezvous message field. Message consists of (possible zero) fields Messages are self-describing Communication is subject-based (see next slide)
9	Basic Messaging (2) Before sending a message, associate it with a subject (separate operation) Can include a subject for replies (sender needs to subscribe to reply subject to receive reply) Optimizations for point-to-point communication Communication primitives: Send (nonblocking) Sendreply (nonblocking, uses reply subject, see above) Sendrequest (blocking, waiting for reply) Receive: no! Use events and event listeners (callbacks) instead
10	Events (1) Processing listener events for subscriptions in TIB/Rendezvous. Listener events: subscriptions
11	Events (2) Processing incoming messages in TIB/Rendezvous.
12	Events (3) One dispatcher per queue, by default only one queue. More control: create/manage multiple queues Priority scheduling of events through a queue group. A semantically equivalent queue for the queue group with the specific event objects from (a).
13	Naming (1) Names are used to identify subjects To generalize subscriptions: allow wildcards in well-formed subject names Examples of valid and invalid subject names:
14	Naming (2) Examples of using wildcards in subject names.
15	Synchronization (1) Only native ordering guarantee: FIFO per source Transactional messaging: separate layer in TIB/Rendezvous. Supports transactional grouping within a single process only!
16	Synchronization (2) The organization of a transaction in TIB/Rendezvous: store messages in transaction daemon until commit.
17	Reliable Communication Assume underlying network inherently unreliable Rendezvous daemon on publishing side keeps copy of message for at least 60 seconds Each outgoing message has transparent sequence number: receiving daemons can detect missed messages and ask for retransmission (based on protocol known as Pragmatic General Multicast): A message is sent along a multicast tree A router will pass only a single NACK for each message A message is retransmitted only to receivers that have asked for it.
18	Reliable Communication (2)
19	Security Problem: how to ensure authentication if referential uncoupling? Allow secure channel for point-to-point connections, assume existence of certificates and established shared secret key using Diffie-Hellman key exchange, for example) K: keys, R: nonce, H: hash value, signed with secret key
20	Generative Communication: Tuples Originally proposed by Gelernter in 1985 in a system called Linda Completely decouples communication entities referentially and temporally Tuple-space: persistent shared storage, processes can add tuples, search matching tuples, and remove tuples Write, read, take Tuples do not have a priori agreed-upon structure Tuple matching is called associative addressing (retrieve tuple based on matched content)
21	Generative Communications: Tuple-spaces JavaSpaces is an implementation of the concept of tuple-spaces, and is used by Jini
22	Communication Events Using events in combination with a JavaSpace
23	Realizing Tuple-Space Trivial if all coordinating processes access same memory: One centralized tuple-space Issues: increase performance of matching operation Subdivide tuple-space into tuples of same type Use hashing, based on first (few) fields in tuple within subspace If processes execute on different machines, how to organize an efficient distributed tuple-space Full replication (good for reading) Full distribution (good for writing) Partial replication Design of efficient wide-area tuple space as yet unsolved problem
24	Fully Replicated Tuple-Space A JavaSpace can be replicated on all machines. The dotted lines show the partitioning of the JavaSpace into subspaces Tuples are broadcast on WRITE READs are local, but the removing of an instance when calling TAKE must be broadcast
25	Fully Distributed Tuple-Space Fully Distributed JavaSpace. A WRITE is done locally. A READ or TAKE requires the template tuple to be broadcast in order to find a tuple instance Move tuple to requesting site, locality of reference will cause good performance
26	Partially Replicated Tuple-Space Partial broadcasting of tuples and template tuples. Similar to a quorum system Assume tuple-spaces are logically organized as a grid: Write: all spaces in same row Read: all spaces in same column
27	What is Jini? “makes computers and devices able to quickly form impromptu systems unified by a network” based on Java (JDK1.2)
28	The Jini Architecture: Key concepts and components Services Lookup Service RMI Security Leasing Transactions Events
29	Jini Lookup Service Repository of available services Stores services as Java objects Clients download services on demand Note: could, in principle, use JavaSpaces, but decision was to implement more specific, specialized (and presumably more efficient) service as part of low-level infrastructure
30	How it works
31	The Jini Lookup Service (1) The organization of a service item ServiceID: globally unique 128 bit ID generated by lookup service Service: reference to remote object, access through RMI AttributeSets: Name-Value tuples describing service, used for lookup by clients
32	The Jini Lookup Service (2) Examples of predefined tuples for service items.
33	Discovery Protocol Services/Clients need to locate a Lookup Server Jini does NOT use well-known address Discovery: process of finding lookup services, used by both Jini services and clients Discovery Model Multicast discovery for LAN Lookup services can also periodically broadcast their presence