20.4 Request-Reply ProtocolsIn the simple-request protocol, the client cannot distinguish the scenario of Figure 20.3 from those of Figure 20.4 and Exercise 20.7 because it does not receive an acknowledgment of its request or any results produced by the request. A request-reply protocol handles this problem by requiring that the server respond to the client. Figure 20.5 shows a sequence of steps, using UICI UDP, to implement a simplified request-reply protocol. If no errors occur, the server's reply message notifies the client that the transmission was successful. The server reply message can contain actual results or just a flag reporting the status of the request. Figure 20.5. Sequence of steps in an error-free request-reply protocol.![]() Program 20.3 shows the server-side implementation of the request-reply protocol of Figure 20.5. The server receives a request and uses u_gethostinfo to extract the identity of the client. After printing the client's name and request to STDOUT_FILENO, the server uses u_sendto with the u_buf_t structure (senderinfo) returned from u_recvfrom to respond to that client. The UICI UDP u_sendto function uses the u_buf_t structure as the destination address to ensure that the reply is directed to the correct client. The server shown here replies with a copy of the request it received. Exercise 20.8An important consideration in writing a server is to decide which conditions should cause the server to exit, which conditions should be ignored, which conditions should be logged and which conditions should trigger a recovery procedure. The server of Program 20.3 never exits on its own once its port is bound to the socket. You can terminate the server by sending it a signal. Under what conditions would it be reasonable for a server such as an ftp server to exit?Answer:You could argue that an ftp server should never exit because it should be running at all times. Certainly, an error caused by a client should not terminate the server. Even if system resources are not available to handle a connection, the problem might be temporary and the server would continue to work after the problem is resolved. Errors should be logged so the administrator has a record of any problems. Program 20.3 server_udp_request_reply.cA server program that implements a request-reply protocol.
Program 20.4 shows a client that uses the request-reply protocol of Figure 20.5. The request is just a string containing the process ID of the requesting process. The protocol is implemented in the request_reply function shown in Program 20.5. The client sends the initial request and then waits for the reply. Since anyone can send a message to an open port, the client checks the host/port information against the sender information supplied in senderinfo to make sure that it received the reply from the same host that it sent to. Program 20.4 client_udp_request_reply.cA client program that sends a request containing its process ID and reads the reply.
Exercise 20.9What happens when the scenario of Figure 20.4 occurs for the request-reply protocol of Figure 20.5?Answer:The client hangs indefinitely on the blocking u_recvfrom call. Program 20.5 request_reply.cRequest-reply implementation Aassumes error-free delivery.
Exercise 20.10Compile Programs 20.3 and 20.4. Start the server on one machine (say, yourhost) with the following command.
Run clients on different hosts by executing the following on several machines.
Put timing statements in Example 9.8.) Run the client program several times. Do any of the instances hang? Under what circumstances would you expect the client to hang?Answer:The client blocks indefinitely on u_recvfrom if it does not receive the reply from the server. Modern networks have become so reliable that if the client and server are running on the same local area network (LAN), it is unlikely that either the request or the reply messages will be lost because of errors along particular wires. In high-congestion situations, packets may be dropped at LAN switches. If many clients are making simultaneous requests, the network subsystem of the server host might discard some packets because the communication endpoint's buffers are full. Messages from clients and servers on different LANs generally follow paths consisting of many links connected by routers. Congested routers drop messages that they can't handle, increasing the likelihood that a message is not delivered. Exercise 20.11Figure 20.6 illustrates the timing for the request-reply protocol when there are no errors. When errors are possible, the nine events listed in the following table can occur in various orders.
What other event sequences represent possible scenarios for request-reply?Answer:
Many other event sequences represent realizable scenarios. Figure 20.6. Timing diagram of the request-reply protocol.![]() |