This preview shows page 1. Sign up to view the full content.
Unformatted text preview: 1618688001 S
(0) sun.1093 > bsdi.7777: ack 1
sun.1092 > bsdi.7777: S
bsdi.7777 > sun.1092: S 4190496001: 417 049
sun.1092 > bsdi.7777: ack 1 Figure 18.24 tcpdump output for backlog example.
We try to start a third client in segment 7 (port 1092), and a fourth in segment 8 (port 1093). file:///D|/Documents%20and%20Settings/bigini/Docu...homenet2run/tcpip/tcp-ip-illustrated/tcp_conn.htm (33 of 37) [12/09/2001 14.47.16] Chapter 18. TCP Connection Establishment and Termination TCP ignores both SYNs since the queue for this listening end point is full. Both clients
retransmit their SYNs in segments 9, 10, 11, 12, and 15. The fourth client's third retransmission
is accepted (segments 12-14) because the server's 30-second pause is over, causing the server to
remove the two connections that were accepted, emptying its queue. (The reason it appears this
connection was accepted by the server at the time 28.19, and not at a time greater than 30, is
because it took a few seconds to start the first client [segment 1, the starting time point in the
output] after starting the server.) The third client's fourth retransmission is then accepted
(segments 15-17). The fourth client connection (port 1093) is accepted by the server before the
third client connection (port 1092) because of the timing interactions between the server's 30second pause and the client's retransmissions.
We would expect the queue of accepted connections to be passed to the application in FIFO (first-in, first-out)
order. That is, after TCP accepts the connections on ports 1090 and 1091, we expect the application to receive
the connection on port 1090 first, and then the connection on port 1091. But a bug has existed for years in many
Berkeley-derived implementations causing them to be returned in a LIFO (last-in, first-out) order instead.
Vendors have recently started fixing this bug, but it still exists in systems such as SunOS 4.1.3. TCP ignores the incoming SYN when the queue is full, and doesn't respond with an RST,
because this is a sof...
View Full Document
- Spring '12