Distributed Systems

Distributed Systems Topic 3: Communication Dr. Michael R. Lyu Computer Science & Engineering Department The Chinese University of Hong Kong

Outline 1 Communication Primitives 2 Client/Server Communication 3 Group Communication 4 CORBA Event Service 5 Summary

PSE (packet switching exchange) host host PSE PSE 1 Communication Primitives The ISO/OSI Reference Model: HTTP, FTP, Telnet CORBA IIOP Application XDR, CORBA Data Secure Sockets (SSL) Presentation for connection- oriented comm. Session Transport message; TCP, UDP Network packet;IP; ATM VC Data link error-free trans. PPP, CSMA/CD Physical ISDN, baseband signaling

1.1 ISO/OSI Transport Layer • Level 4 of ISO/OSI reference model. • Concerned with the transport of information through a network. • Two facets in UNIX networks: • TCP • UDP Application Presentation Session Transport Network Data link • connection oriented • virtual connection • w sequencing & • acknowledgement Physical • connectionless • up to 64k bytes datagram • no seqs and acks

1.1 ISO/OSI Transport Layer (TCP) • Transmission Control Protocol (TCP) provides bi-directional stream of bytes between two distributed components. • UNIX rsh, rcp and rlogin are based on TCP. • Reliable but slow protocol. • Buffering at both sides decouples computation speeds.

1.1 ISO/OSI Transport Layer (UDP) • User Datagram Protocol (UDP) enables a component to pass a message containing a sequence of bytes to another component. • Other component is identified within message. • Unreliable but very fast protocol. • Restricted message length. • Queuing at receiver. • UNIX rwho command is UDP based.

1.2 ISO/OSI Presentation Layer • At application layer: complex data types • How to transmit complex values through transport layer? • Presentation layer issues: • Complex data structures and • Heterogeneity. Application Presentation Session Transport Network Data link Physical

Marshalling: Disassemble data structures into a transmittable form Unmarshaling: Re-assemble the complex data structure. 1.2 Complex Data Structures class Person { private: int dob; char * name; public: char * marshal() { char * msg; msg=new char[strlen(name)+10]; sprintf(msg,”%d,%d,%s”, dob, strlen(name),name); return(msg); }; };

1.2 Heterogeneity • Heterogeneous data representation on different hardware platforms. • Approach 1 (Example XDR): • Define a shared representation, • For each different platform, provide mapping between common and specific representation. • Approach 2 (Example ASN):

1.3 Communication Patterns • Basic operations: send and receive messages (as in UDP). • Message delivery: • Synchronous or • Asynchronous • Messages are used to model: • Notification and • Request.

(1) (2) (3) (4) (5) sender blocked send Transport Layer ackn receive receiver blocked Time 1.3 Synchronous Communication

P1 Waits-for P2 1.3 Communication Deadlocks • Components are mutually waiting for each other. • To avoid deadlocks: Waits-for relation has to be acyclic! P1: send() to P2; receive() from P2; P2: send() to P1; receive() from P1;

(1) (2) (3) (4) sender send Transport Layer receive receiver blocked Time 1.3 Asynchronous Communication

send(...) receive(...) Notifier Notified 1.3 Notification • Uni-directional communication • Message contains marshaled notification parameters.

request receive(...) send(...) receive(...) ... send(...) reply Requester Provider 1.3 Request • Bi-directional communication. • Request message contains marshaled parameters. • Requester receives reply message. • Reply message contains marshaled results.

1.3 Reliability Issues • Unreliable message refers to message transmission without acknowledgement or retries (e.g., UDP). • A reliable delivery service may be constructed from an unreliable one by the use of ack. • Positive ack. for client-server communication and negative ack. for group multicast. • Reliable communication involves overheads. • Each message should have a unique identifier.

2 Client/Server Communication • Qualities of service. • Request protocol (R). • Request reply protocol (RR). • Request reply acknowledgement protocol (RRA).

2.1 Qualities of service • Exactly once, • At most once, • At least once and • Maybe?

execution request send(...) receive(...) exec op; Client Server 2.2 Request Protocol • If service • does not have out or inout parameters and • does not have a return type client may not want to wait for server to finish.

request send(...) receive(...) receive(...) exec op; send(...) reply Client Server 2.3 Request/Reply Protocol • To be applied if client expects result from server. • Client requests service execution from server through request message. • Delivery of service result in reply message.

request send(...) receive(...) send (...) receive(...) exec op; send(...) receive(...) reply ackn Client Server 2.4 RRA Protocol • In addition to RR protocol, client sends acknowledgement after it received reply. • Acknowledgement sent asynchronously.

3 Group Communication • Client/server requests: • There is no other party involved. • Client has to identify server. • Sometimes other properties are required: • Communication between multiple components. • Anonymous communication.

Broadcast: Send msg to a group. Multicast: Send msg to subgroup only. N N N N N N M N N N N M M N N N N N N N N N N N N 3.1 Concepts • Useful applications: • Fault tolerance • Object location • Better performance • Multiple update

R1 S Time R2 R1 S Time R2 3.2 Qualities of Service • Ideal: Immediate and reliable. • Optimal: Simultaneous and reliable.

R1 S Time R2 R1 S Time R2 3.2 Qualities of Service • In reality: not simultaneous ... ... and not reliable

3.2 Qualities of Service • Problem: To achieve reliable broadcast/multicast is very expensive. • Degrees of reliability: • Best effort, • K-reliability, • totally ordered, • Atomicity. • Choose the degree of reliability needed and be prepared to pay the price.

3.3 CORBA Event Management • CORBA event management service defines interfaces for different group communication models. • Events are created by suppliers (producers) and communicated through an event channel to multiple consumers. • Service does not define a quality of service (left to implementers).

3.3.1 Push Model • Consumers register with those event channel through which events they are interested in are communicated. • Event producers create a new event by invoking a push operation from an event channel. • Event channel notifies all registered consumers by invoking their push operations.

Share value updated Redisplay chart Redisplay table Event Channel Producer Consumer Consumer push(...) push(...) push(...) 3.3.1 Push Model (Example)

3.3.2 The Pull Model • Event producer registers its capability of producing events with event channel. • Consumer obtains event by invoking pull operation from event channel. • Event channel asks producer to produce event and delivers it to the consumer.

Current value: 76.10 Current share value? Event Channel Producer Consumer Consumer pull(...) pull(...) 3.3.2 Pull Model (Example)

Push consumer Push supplier Event Channel Direction of event transfer Pull supplier Pull consumer 3.3.2 Event Channel • Supported combinations: • push suppliers, push consumers • push suppliers, pull consumers • pull suppliers, push consumers • pull suppliers, pull consumers

3.3.2 Event Channel (with proxies) Proxy push consumer Proxy push supplier Push consumer Push supplier Event Channel Direction of event transfer Proxy pull consumer Proxy pull supplier Pull supplier Pull consumer

4 Summary • What communication primitives do we use? • How are differences between application and communication layer resolved? • What quality of service do the client/server protocols achieve that we discussed? • What quality of services are involved in group communication? • CORBA Event Service for group communication. • Read Textbook Chapter 3 through Chapter 4.

Homework #1 • 1.7 Total 10 questions, 10 points each • 1.11 • 1.13 Due: 7/10/2003 (Tuesday) in class • 2.9 • 2.13 • 3.1 • 3.7 • 3.9 • 4.7 • 4.21

Distributed Systems