TCP IP Illustrated

Both clients retransmit their syns in segments 9 10

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: 1618688001 S (0) S (0) S (0) S (0) S (0) S (0) S (0) sun.1093 > bsdi.7777: ack 1 sun.1092 > bsdi.7777: S 1618176000:1618176000(0) bsdi.7777 > sun.1092: S 4190496001: 417 049 6001(0) ack 1618176001 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

Ask a homework question - tutors are online