Interprocess Communications

1. Interprocess Communications Natalia Khuri & Seetharam Samptur

2. Outline • Introduction to IPC • Computer networks • Protocols for remote operations • Remote Procedure Calls • Conclusion

3. What is IPC? • IPC mechanisms allow processes to communicate and to synchronize their actions without sharing the same address space. • IPC mechanism in a distributed system should make communication transparent.

4. Traditional IPC • How do we pass information from one process to another? • Pipes, shared memory. • How do we avoid race conditions and achieve mutual exclusion? • Mutexes, lock variables, semaphores. • How do we schedule processes when dependencies are present? • Batch, interactive, real-time.

5. Distributed IPC • How do we support communication over a network? • How do we hide the distinction between local and remote communication? • How do we deliver information with minimum latency, maximum throughput and minimum jitter? • How do we shield one process from failures of another? • How do we ensure security?

6. Distributed Communication • All communication in distributed system is based on low-level message passing as offered by the underlying network. • Process A builds a message in its own address space and executes a system call that causes the operating system to send the message over the network to process B.

7. What Do We Need? • Good network infrastructure. • Efficient protocol stack. • Transport protocol to handle various types of data. • Communication models. • Security.

8. Network Requirements • Ability to transfer any data type: • Bulk, voice, video. • Minimum latency, maximum throughput, minimum jitter. • Error detection and correction: • Physical medium is never error-free. • Different types of networks: • Local Area Networks (LAN) • Metropolitan Area Networks (MAN) • Wide Area Networks (WAN)

9. Asynchronous Transfer Mode • Communication technology that uses high-bandwidth, low-delay transport technology, and multiplexing techniques. • ITU standard for cell relay in which multiple service type (such as voice, video, or data) are conveyed in fixed-length. • ATM networks are connection-oriented. • ATM Services: • Constant/variable bit rate • Available/unspecified bit rate

10. Switching • Packet Switching: • No predefined paths, e.g. traditional LAN. • Circuit Switching: • Specific path set up for each connection, e.g. telephone networks. • ATM Switching: • Hybrid of packet and circuit switching. • Multiple connections over a predefined path.

11. ATM Network Operation ATM devices: • ATM Switches. • ATM endpoints, e.g. workstations, video coders/decoders. • User-Network Interface (UNI) & Network-Node Interface (NNI).

12. ATM Virtual Connection • Virtual Channel: • End-to-end connection • Virtual Path: • Bundle of virtual channels that have local significance.

13. ATM Path Switching ATM Switching: • Uses VCI & VPI from the cell. • Uses translation/routing table.

14. ATM Protocol Data Unit

15. Why 48-byte Cells? • Telephone quality audio is sampled at 8000 Hz using 8-bit samples. • PTTs send a packet every 6 msec each containing 48 bytes of audio. • (1/8000) * 48 = (125 usec) * 48 = 6 msec • Smaller header is required to assist in faster switching of packets in the network.

16. Protocol Organization • Different agreements (protocols) are needed in message exchanges: • Number of volts per bits • Data type representation • Error detection and recovery • The Open Systems Interconnection Reference (OSI) model identifies the standard rules that govern the format, contents, and meaning of the messages.

17. OSI Layers • Physical Layer: • Interface to physical medium. • Data Link Layer: • Reliable transit of data over the physical link. • Network Layer: • Routing packets in the network. • Transport Layer: • Consistent end-to-end delivery of the packet to applications.

18. Mapping ATM to OSI • Physical Layer: • medium dependent transmissions. • ATM layer: • Connection setup and passing of the cells. • ATM Adaptation Layer: • isolates higher layer protocols from ATM processes.

19. Demultiplexing • ISO OSI model allows multiplexing and demultiplexing in six of the seven layers. • Faster in ATM: • Fewer layers in ATM stack. • Support for virtual circuits at MAC level. • Virtual channels expedite demultiplexing.

20. Classes of Communication Protocols • Four classes of communication protocols: • Remote Operations (Client/Server, Request/Response) • Bulk data management (File transfer protocol) • One-to-many communication (Multi-/Broadcasting) • Continuous Media (Video/Audio) • The diversity of communication requirements in a distributed system prohibits the use of a single transport protocol.

21. Remote Operations • The most basic form of communication in distributed systems. • Process A (client process) sends a message to process B asking it to do some work. • Process B (server process) carries out work and returns a message with the result. • Client and server can be the same process. • Return message can merely be ACK.

22. Bulk Data Transfer • Very large request or response messages. • Bulk data transfer can be viewed as a special form of remote operation. • When data goes to the client, the operation can be viewed as a read operation. • When data comes from the client, the operation can be viewed as a write operation. • Request/response protocols are very efficient.

23. One-to-Many Communication • Services that use replication to tolerate failures. • Large amounts of internal communication is needed to keep the replicas consistent. • It is important that this communication reaches all replicas in a well-defined order. • In practice, replication protocols are always multicast protocols.

24. Continuous Media • Multimedia networks require low-latency and constant-rate data transport for continuous media and low-latency for “normal” data. • ATM networks appear to be good at allowing the mixture of these data types.

25. Fundamental Properties of Protocols • Message delivery: • At-least-once. • At-most-once. • Feedback: • End-to-end application-level acknowledgement. • Error report on failures. • Low end-to-end latency. • Support large request/response messages.

26. Communication Failures • Networks exhibit failures that manifest themselves as lost packets. • If not all packets are lost, these failures can be corrected using feedback: • Acknowledgements, timeouts. • Communication protocols cannot be made completely reliable: • Client cannot distinguish a server that went down from one that has become disconnected.

27. Unresponsive Server

28. Amnesia Failure • A processor suddenly stops (crashes) and forgets all its state. • It resumes operations from the initial state (reboots). • At-most-once message delivery cannot be achieved: • Aim for at-least-once message delivery.

29. Recovering From Failure • Session management: • Unique session identifier. • Guaranteed at-most-once message delivery. • End-to-end acknowledgement: • No dependence on protocol stack. • Positive feedback about delivery and response can only be provided by an end-to-end application level acknowledgement.

30. At-most-once Delivery • Session management is essential to provide at-most-once delivery. • Delta-T protocol • Sessions are alive until packets are exchanged and until a no-traffic timer expires. • New sessions are created by timeouts that last for a period of ∆T. • ∆T = transmission delay + max. # of retrans. + time interval between retransmissions.

31. Delta-T Protocol

32. Two-way Handshake with Piggybacking • Positive feedback when no failure occurs. • Protocol: • Client sends a request and starts a retransmission timer • Server responds to the client before the retransmission timer expires. The response is also an acknowledgement for the request. • Client sends the next request, which also acts as an acknowledgement for the prior response. • If the client does not have any request to send, the client will acknowledge thelast response before terminating.

33. Two-way Handshake with Piggybacking

34. Optimized Two-way Handshaking • Error report on failures. • Protocol: Client sends a request and starts a timer While retransmission count is not zero Do If ACK received Send request header only Else Send request Restart timer Reduce retransmission count End While

35. Optimized Two-Way Handshaking

36. Packet Blast Protocol • Support large request and response messages. • Fixed number of packets sent as a blast and acknowledged as one unit. • Retransmit all packets in the blast if no acknowledgement received.

37. Packet Blast Protocol

38. Messages • Initially: hand-coded messages to send requests and responses: • Hand-coding messages gets tiresome. • Need to worry about message formats. • Have to pack and unpack data from messages. • Have to decode and dispatch messages to handlers. • Messages are often asynchronous. • Messages are not a natural programming model (Birrell and Nelson, 1984): • Could encapsulate messaging into a library. • Invoke library routines to send a message.

39. Procedure Calls • Procedure calls - more natural way to communicate: • Every language supports them. • Natural for programmers to use. • Idea: Servers can export a set of procedures that can be called by client programs • Similar to module interfaces, class definitions, etc. • Clients just do a procedure call as it they were directly linked with the server. • Under the covers, the procedure call isconverted into a message exchange with the server.

40. Implementing RPC • No architectural support for making remote procedure calls. • Simulate it with available tools: • local procedure calls and • sockets for network communication. • This simulation makes remote procedure call a language levelconstruct as opposed to sockets, which are an operating system level construct: • Compiler knows that remote procedure calls need special code.

41. Implementing RPC • Trick: • Create stub functions that make it appear to the user that the call is really local. • A stub function looks like the function that the user intends to call but really contains code for sending and receiving messages over a network.

42. Functional Steps in RPC W. Richard Steven “UNIX Network Programming”

43. Benefits • Procedure call interface. • Writing applications simplified: • RPC hides all network code into stub functions. • Application programmers don’t have to worry about details: • Sockets, port numbers, byte ordering. • Presentation layer in OSI model.

44. Implementation Issues • How do we make this invisible to the programmer? • What are the semantics of parameter passing? • How do we bind (locate, connect to) servers? • How do we support heterogeneity (OS, architecture, language)? • How do we make it perform well? • How do we deal with failures? • Client and server can fail independently.

45. RPC Messages • RPC uses a message-based communication scheme to provide remote service. • RPC messages are well structured (no longer just packets of data): • addressed to an RPC daemon listening to a port on a remote system • contain an identifier of the function to execute and the parameters to pass to that function.

46. RPC Model • A server defines the server’s interface using an interface definition language (IDL) • The IDL specifies the names, parameters, and types for all client-callable server procedures. • A stub compiler reads the IDL and produces two stub procedures for client and server: • The server programmer implements the server procedures and links them with the server-side stubs. • The client programmer implements the client program and links it with the client-side stubs. • The stubs are responsible for managing all details of the remote communication between client and server.

47. RPC Stubs • A client-side stub looks to the client as if it were a callable server procedure. • A server-side stub looks to the server as if a client called it. • The client program thinks it is calling the server (In fact, it is calling the client stub). • The server program thinks it is called by the client (In fact, it is called by the server stub). • The stubs send messages to each other to make the RPC happen “transparently”.

48. Marshalling • Marshalling is the packing of procedure parameters into a message packet. • The RPC stubs call type-specific procedures to marshal (or unmarshall) the parameters to a call • The client stub marshals the parameters into a message. • The server stub unmarshalls parameters from the message and uses them to call the server procedure. • On return: • The server stub marshals the return parameters. • The client stub unmarshalls return parameters and returns them to the client program.

49. Marshalling Goals • Linearize the data structures for transport in messages and reconstructing the original data structures at the other end. • Convert data structures from the data representation on the calling process to that of the called process.

50. Linearizing • Pointers: • Do not marshal the data pointed to, but generate a call-back handle. • Avoid unnecessary copying of data across the interface. • Multiple pointers to the same data will usually go unrecognized. • Implicit typing: • only values are transmitted, not data types or parameter info, e.g., Sun XDR. • Explicit typing: • Type is transmitted with each value, e.g., ASN.1, XML.