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 syn-
![](https://steemitimages.com/DQmamSmA3y4brKYxcDgQbRSogyotgnHYWFt4qWn7UD3cJje/image.png)
Figure 1.2: Synchronous versus Asynchronous Messaging Strategies

• 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