Java Reference
In-Depth Information
Sending implementation
Receiving implementation
Receiving program
SendQ
RecvQ
Delivered
3
3
2
2
1
500 bytes
6000 bytes
1500 bytes
1
2
3
First write (1000 bytes)
Second write (2000 bytes)
Third write (5000 bytes)
Figure 5.3: After first read() .
Sending implementation
Receiving implementation
Receiving program
SendQ
RecvQ
Delivered
3
3
3
2
1
500 bytes
2000 bytes
5500 bytes
1
2
3
First write (1000 bytes)
Second write (2000 bytes)
Third write (5000 bytes)
Figure 5.4: After another read() .
implementation to the receive-side implementation. The movement of data from the SendQ to
the RecvQ buffer has important implications for the design of application protocols. We have
already encountered the need to parse messages as they are received via a Socket when in-
band delimiters are used for framing (see Section 3.3). In the following sections, we consider
two more subtle ramifications.
5.2
Buffer Deadlock
Application protocols have to be designed with some care to avoid deadlock —that is, a state
in which each peer is blocked waiting for the other to do something. For example, it is
pretty obvious that if both client and server try to receive immediately after a connection
is established, deadlock will result. Deadlock can also occur in less immediate ways.
The buffers SendQ and RecvQ in the implementation have limits on their capacity.
Although the actual amount of memory they use may grow and shrink dynamically, a hard
limit is necessary to prevent all of the system's memory from being gobbled up by a single
Search WWH ::




Custom Search