Block 2: Client server paradigm and event synchronization

1. Block 2: Client server paradigm and event synchronization Jin Sa Client-Server Programming

2. Outline of block 2 • Client server and peer-to-peer paradigms • Concepts of clients and servers • Interface between process and network (socket) • Characteristics of operations • Event synchronisation • Synchronous and asynchronous • Event diagram • Indefinite blocking, deadlocks and timeout Client-Server Programming

3. Application architectures • To develop a network application, we need to first decide the application architecture, i.e. how the network application is structured over the end systems. • Two main architectural paradigms • Client-server • Peer-to-peer (P2P) Client-Server Programming

4. Typical network application has two types of programs: client and server request reply Client-server paradigm application transport network data link physical application transport network data link physical Client-Server Programming

5. Client-server paradigm • Server: • always-on, provides requested service to client • e.g., Web server sends requested Web page, mail server delivers e-mail • Client: • initiates contact with server (“speaks first”) • typically requests service from server, • Web: client implemented in browser; e-mail: in mail reader Client-Server Programming

6. More on Client-server paradigm • Often a single host is incapable of keeping up with all the requests, e.g. Nothern Rock, Game (Nintendo Wii), e-Bay • Virtual server via a cluster of hosts – server farm • Client-server architecture can be infrastructure intensive. Providers pay costs for sending and receiving data. • Examples are • search engine: Google, • Internet commence: Amazon and e-Bay, • Web-based email: Yahoo Mail, • social networking: MySpace and Facebook, • video sharing: YouTube Client-Server Programming

7. Peer-to-peer paradigm • Minimal or no reliance on always-on server • Direct communications between intermittently connected hosts (peers) • Examples are: • File distribution: BitTorrent • File searching/sharing: LimeWire • Internet telephony: Skype • BBC iPlayer • Hybrid architecture: combining both client-server and p2p, e.g. instant messaging applications servers track user IP addresses, but user-to-user messages are sent directly to each other Client-Server Programming

8. Client and server processes • Network application consists of pairs of processes, client and server, exchanging messages • E.g. In the Web, client browser process exchange messages with a Web server process • E.g. P2P file sharing, the peer downloading is regarded as the client, the peer uploading the file is regarded the server. • A process can be both a server and a client. Client-Server Programming

9. client or server Client or server process process socket socket TCP or UDP TCP or UDP Socket: interface between the process and the network • process sends/receives messages to/from its socket • socket analogous to door • sending process shoves message out door • sending process assumes transport infrastructure on other side of door which brings message to socket at receiving process controlled by app developer Internet Client-Server Programming

10. Both UDP and TCP use the Socket abstraction which support the notion of send and receive TCP also provides the notion of connect. 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 Basic socket operations provided in Transport layer Client-Server Programming

11. Characteristics of interprocess communications • Sending processes cause messages to be added to the remote message queues. • Receiving processes remove messages from the local queues. • Communications between sending and receiving processes can be either synchronous or asynchronous Client-Server Programming

12. Synchronous Communication • The sending process and the receiving process synchronize at every message • Both the send and the receive are blocking operations. • Whenever a send is issued, the sending process is blocked until the receive is issued. • Whenever a receive is issued, the receiving process is blocked until a message arrives. Client-Server Programming

13. Asynchronous communication • Send is non-blocking. • The sending process proceeds with the rest of the computation as soon as the message is copied to a local buffer • The transmission of the message happens in parallel with the sending process • The receive operation can be either non-block or block. Client-Server Programming

14. Asynchronous with non-blocking receive • In the non-blocking case, the receiving process proceeds with its program after issuing the receive operation • Runtime system provides a buffer in the background to receive the message • The receiving process need to make sure that it can receive a notification that the buffer is filled by either polling or interrupt. Otherwise the receiving process may not receive the message at all. Client-Server Programming

15. Synchronous vs asynchronous • Non-blocking communications appear to be more efficient as the processes do not wait. But it involves extra complexity in the receiving process to make sure that the message is received • Although blocking receive may (appear to) be inefficient due to the waiting, it is simpler logically. In addition, in a multithreaded environment, the programmer can use a separate thread to issue the block receive, therefore not blocking the rest of the process. Client-Server Programming

16. Event synchronization • When processes communicate with each other, it may require synchronization with their operations: • See the different scenarios in the next few slides Client-Server Programming

17. Synchronous communication: blocking send and blocking receive Sending process Receiving process execution flow beginning of send blocked period beginning of receive start of operation ack of data received Client-Server Programming

18. Asynchronous communication: non-blocking send and blocking receive Sending process Receiving process beginning of receive send Client-Server Programming

19. Asynchronous communication: non-blocking send and blocking receive Sending process Receiving process beginning of send beginning of receive Note the indefinite blocking for the receiving process Client-Server Programming

20. Asynchronous communication: non-blocking send and non-blocking receive Sending process Receiving process beginning of send receive data already in the buffer, receive operation get the data Client-Server Programming

21. Asynchronous communication: non-blocking send and non-blocking receive Sending process Receiving process data not arrived yet, so no data is received unless the program repeatedly polls the data from the buffer or receives interrupt when the data arrives receive send Client-Server Programming

22. Indefinite blocking and deadlocks • Operations can result in indefinite blocking, e.g. • blocking connect request can result in the requesting process to be suspended indefinitely if the connection is unfulfilled, perhaps as a result of a breakdown in the network. • Operations are out of sync as shown above. • One type of indefinite block is called deadlock. For example, if two processes both issue a blocking receive operation to try to receive data from each other at about the same. Neither will receive any data and neither will come out of the blocking. Client-Server Programming

23. Timeout • It is generally unacceptable for a requesting process to “hang” indefinitely. • Both TCP and UDP at the transport layer provide an API to allow the programmers to set a timeout period. • Indefinite blocking can be avoided by setting a timeout period on the operations. A process will come out of the blocking after the timeout period. Client-Server Programming

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

25. Event diagram • Event diagram can be used to document the detailed sequence of events and blocking during the exchanges of messages. • 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

26. Question 1 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

27. Question 2 answer Client-Server Programming

28. Question 2 answer Client-Server Programming

29. 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

30. Question 3 answer Client-Server Programming

31. Review questions On completion of block 2, you should • Understand the client server and peer-to-peer paradigms • Understand socket as the interface between process and network • Know the characteristics of interprocess communications: synchronous and asynchronous communications • understand event synchronisation • Be able to draw event diagrams to illustrate the events • understand the concept of deadlock and timeout Client-Server Programming