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
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:
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:
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 |