1.2 Synchronous versus Asynchronous Message Exchange

I l @ ve RuBoard

In many networked applications, a client sends a request to a server, which processes the request and then sends back a response. These request/response protocols can be implemented over either connectionless or connection-oriented protocols. Two alternative strategies for arranging request/response protocol exchanges are synchronous and asynchronous, as shown in Figure 1.2. The two factors that affect whether to use synchronous or asynchronous message exchange strategies are

  1. The interrelatedness of requests and

  2. The latency of the underlying protocol or communication media.

Figure 1.2. Synchronous versus Asynchronous Messaging Strategies

We examine how these factors affect the choice of strategy below.

Synchronous request/response protocols are the simplest form to implement. In these protocols, requests and responses are exchanged in a lock-step sequence. Each request must receive a response synchronously before the next is sent, as shown in Figure 1.2 (1). Synchronous request/response protocols are appropriate in the following contexts:

  • When the result of a request determines subsequent requests, for example, an application that requires an authentication exchange won't send sensitive information requests until the security certificate exchange completes successfully

  • When applications exchange messages requiring short-duration processing in low-latency networks, such as NFS read() and write () operations in high-speed LANs

  • When simplicity of implementation or a small number of protocol exchanges overrides any possible performance improvement that may be gained by the asynchronous request/response protocols described next.

Asynchronous request/response protocols stream requests from client to server without waiting for responses synchronously [AOS + 00]. Multiple client requests can be transmitted before any responses arrive from a server, as shown in Figure 1.2 (2). Asynchronous request/response protocols therefore often require a strategy for detecting lost or failed requests and resending them later. Asynchronous request/response protocols are appropriate in the following contexts:

  • When a response is not required before deciding on subsequent requests. For example, Web browsers can use asynchronous strategies to fetch multiple embedded images from the same server. Since each request is independent, they can all be sent asynchronously without waiting for the intervening responses. Each response includes information the browser can use to match it to the corresponding request even when the order of responses is different from the order the requests were sent.

  • When communication latency is high relative to the processing time required for the request. Asynchronous request strategies help to make efficient use of the network, reducing the effects of high latency. The resulting performance improvement greatly outweighs the extra complexity of associating responses with requests and correctly implementing retry strategies.

Logging service Our networked logging server uses a one-way variant of an asynchronous request/response protocol that doesn't require application-level responses. Log records are just transferred from client applications to the logging server; that is, there's no need for application-level acknowledgments from the server. The logging server itself writes each log record to disk immediately after receiving it, with the assumption that each log record sent is recorded reliably. This design suffices as long as client applications don't require the networked logging service to take heroic measures to guarantee that all log records are stored persistently, even when catastrophic failures occur. If this became a requirement, we'd need to develop a transaction-based logging service, which is much more complicated and incurs significantly higher time/space overhead.

I l @ ve RuBoard


C++ Network Programming
C++ Network Programming, Volume I: Mastering Complexity with ACE and Patterns
ISBN: 0201604647
EAN: 2147483647
Year: 2001
Pages: 101

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net