Block 2: Interprocess Communications

1. Block 2: Interprocess Communications Jin Sa Client-Server Programming

2. Outline of block 2 • Characteristics of IPC • Unicast and multicast • Operations in IPC • Event synchronisation • Synchronous and asynchronous • Event diagram • Deadlocks and timeout • Data representation and data marshalling • External representation • Data marshalling and unmarshalling • Text-based protocols Client-Server Programming

3. Interprocess Communications The backbone of distributed computing is interprocess communications (IPC). Distributed computing requires information to be exchanged among independent processes. In distributed computing, two or more processes engage in IPC in a protocol agreed upon by the processes. A process may be a sender at some points during a protocol, a receiver at other points. Client-Server Programming

4. Interprocess Communications in Distributed Computing Client-Server Programming

5. Characteristics of IPC Client-Server Programming

6. IPC – unicast and multicast • When communication is from one process to a single other process, the IPC is said to be a unicast. When communication is from one process to a group of processes, the IPC is said to be a multicast. In this semseter, We will be mainly concerned with unicast. Client-Server Programming

7. Unicast vs. Multicast Client-Server Programming

8. Send transmitting data to a receiving process Receive accept data from a sending process Connect establish a logical connection between two processes. The sending process issues a request for connection, the other process issues an accept connection operation Disconnect de-allocate a previously established connection at both sides Operations provided in Interprocess Communications API Client-Server Programming

9. Interprocess Communication in basic HTTP Client-Server Programming

10. Event Synchronization • Interprocess communication requires that the two processes synchronize their operations: one side sends, then the other receives until all data has been sent and received. • The synchronization requires system support. Client-Server Programming

11. Synchronous vs. asynchronous Communication • The IPC operations may provide the synchronization necessary using blocking. A blocking operation issued by a process will block further processing of the process until the operation is fulfilled. • Alternatively, IPC operations may be asynchronous or nonblocking. An asynchronous operation issued by a process will not block further processing of the process. Instead, the process is free to proceed with its processing, and may optionally be notified by the system when the operation is fulfilled. Client-Server Programming

12. Synchronous send and receive Event diagram Client-Server Programming

13. Asynchronous send and synchronous receive Client-Server Programming

14. Synchronous send and async. receive - 1 Client-Server Programming

15. Synchronous send and async. receive - 1 • The data requested by the receive operation has already arrived at the time the receive operation is issued. In this case, the data is delivered to process 2 immediately, and an acknowledgement from host 2’s IPC facility will unblock process 1. Client-Server Programming

16. Synchronous send and async. receive - 2 Client-Server Programming

17. Synchronous send and async. receive - 2 • The data requested by the receive operation has not yet arrived. Process 1 is blocked indefinitely until process 2 reissue a receive request and an acknowledgement arrives from host 2’s IPC facility. • It is common to use a loop to repeatedly issue a receive operation until the awaited data is received. Client-Server Programming

18. Synchronous send and async. receive - 3 Client-Server Programming

19. Synchronous send and async. receive - 3 • The data requested by the receive operation has not yet arrived. Host 2’ IPC facility will notify process 2 when the data arrives. • This scenarios requires process 2 provide a listener that can be invoked by the IPC facility to notify the process of the arrival of the data. Client-Server Programming

20. Deadlocks and Timeouts • Operations can result in indefinite blocking • For example, a blocking connect request can result in the requesting process to be suspended indefinitely if the connection is unfulfilled or cannot be fulfilled, perhaps as a result of a breakdown in the network . • It is generally unacceptable for a requesting process to “hang” indefinitely. Indefinite blocking can be avoided by using timeout. • Indefinite blocking may also be caused by a deadlock Client-Server Programming

21. Example The daytime service is the simplest network service, whereby a client process obtains a timestamp (the time of day on the server host) from the server process. Is it possible for a daytime client to be blocked indefinitely? Explain your answer. yes, if after issuing a block receive operation, server does not respond and there is no time out defined. Client-Server Programming

22. Indefinite blocking due to a deadlock Client-Server Programming

23. Event diagram • Event diagram can be used to document the detailed sequence of events and blocking during the of a protocol. • The execution of each process with respect to time is represented using a vertical line. • A solid line interval represents a period that the process is active. • A broken line interval represents the process is blocked. Client-Server Programming

24. In class exercisesQuestion1 Q1:Process A sends a single message to process B using connectionless IPC. To do so, A issues a send operation (specifying the message as argument) sometime during its execution, and B issues a receive operation. Suppose the send operation is blocking and the receive operation is non-blocking. Draw an event diagram for each of the following scenario: Client-Server Programming

25. In class exercisesQuestion 1 cont. • Process A issues its send operation prior to process B issues its receive operation. • Process B issues its receive operation prior to process A issues its send operation. Client-Server Programming

26. Question 1 answer The data requested by the receive operation has already arrived, the data is delivered to process B and an acknowledgement from host 2’s IPC facility will unblock process A subsequently. Client-Server Programming

27. Question 1 answer • The data requested by the receive operation has not yet arrived, no data is delivered to the process. It is the receiving process’ responsibility to ascertain that it has indeed received the data and, if necessary, repeat the receive operation until the data has arrived. Process 1 is blocked indefinitely until process 2 reissues a receive request and an acknowledgement eventually arrives from host 2’s IPC facility. Client-Server Programming

28. Question 1 answer • The data requested by the receive operation has not yet arrived. The IPC facility of host 2 will notify process 2 when the data it requested has arrived, at which point process 2 may proceed to process the data. This scenario requires that process 2 provides a listener or event handler which can be invoked by the IPC facility to notify the process of the arrival of the requested data. Client-Server Programming

29. Question 2 Q2: Repeat the last question. This time both operations (send, receive) are blocking. • Process A issues its send operation prior to process B issues its receive operation • Process B issues its receive operation prior to process A issues its send operation. Client-Server Programming

30. Question 2 answer Client-Server Programming

31. Question 2 answer Client-Server Programming

32. Question 3 Three processes P1, P2, P3 are engaged in interprocess • At time 1, P3 issues a receive from P2. • At time 2, P1 sends m1 to P2. • At time 3, P2 issues a receive from P1. • At time 4, P2 receives m1. • At time 5, P2 sends message m1 to P3. • At time 6, P3 receives m1; P1 issues receive from P2. • At time 7, P2 issues a receive from P3. • At time 8, P3 sends m2 to P2. • At time 9, P2 receives m2. • At time 10, P2 sends m2 to P1. • At time 11, P1 receives m2. Draw a time event diagram for P1, P2 and P3 to show the sequence of events. All operations are blocking. Client-Server Programming

33. Question 3 answer Client-Server Programming

34. Notes • In a system environment such as Java, which supports multithreading, the blocking receive has no disadvantages as it can issue a separate thread to handle the blocking receive, and the other threads remain active. • Non-blocking receive appears to be more efficient, but it requires extra complexity in the receiving process. • Many today’s systems do not generally provide the non-blocking receive operation. Client-Server Programming

35. Data Representation and Data Marshalling Client-Server Programming

36. External data representation and marshalling • Information stored in a running program is represented as data structures. • Data transmitted on the network is sequence of bytes. • Therefore data structures must be flattened, i.e. convert to sequence of bytes. Before transmission and rebuilt on arrival. Client-Server Programming

37. External data representation and marshalling • Marshalling is the process of taking a collection of data items and put them into a form suitable for transmission in a message. Unmarshalling is the process of disassembling them on arrival to produce an equivalent collection of data items at the destination. • Marshalling consists of the translation of structured data items and primitive values into an external data representation. Unmarshalling consists of the generation of primitive values from their external data representation and the rebuild of the data structure. Client-Server Programming

38. Examples of external data representation • CORBA’s common data representation • Java’s object serialization • XML a text-based markup language that is fast becoming the standard for data interchange on the Web. Client-Server Programming

39. Client-server communication Client-Server Programming

40. Client-server communication • The IPC form of communication is designed to support roles and message exchanges in typical client-server interaction, where there is a request-reply communication. Client-Server Programming

41. Protocol • In a distributed application, two processes perform interprocess communication in a mutually agreed upon protocol. • The specification of a protocol should include • (i) the sequence of data exchange, which can be described using a time event diagram. • (ii) the specification of the format of the data exchanged. Client-Server Programming

42. Request-reply protocols • An important type of protocol is request-reply protocol • One side issues a request and awaits a response from the other side. • The protocl proceeds in an iteration of request-response until the task is complete. • Popular network protocols, including FTP (File Transfer Protocol) and HTTP, are request-response protocols. Client-Server Programming

43. HTTP: A sample protocol • The Hypertext Transfer Protocol is a protocol for a process (the browser) to obtain a document from a web server process. • It is a request-response protocol: a browser sends a request to a web server process, which replies with a response. Client-Server Programming

44. HTTP session • In its basic form, HTTP is a text-based, request-response protocol that calls for only one round of exchange of messages. • A web server process constantly listens for incoming request. • A web browser process makes a connection to the web server process, then issues a request. • The server processes the request and dispatches a response include the document requested by the browser. • The browser process then parses the response and displays the document. Client-Server Programming

45. Review questions On completion of block 2, you should be able to • Know the operations in IPC • understand event synchronisation • draw event diagrams to illustrate the events • understand the concept of deadlock and timeout • understand data marshalling Client-Server Programming