Re: TCPIP sequence number question
- From: Johnny Billquist <bqt@xxxxxxxxxxxx>
- Date: Mon, 09 Jun 2008 22:55:27 +0200
JF Mezei skrev:
Ok, this isn't specifically VMS related but here it goes...
And this is a little late in answering, but anyway...
Say I am sending TCP data packets with sequence numbers #10 #11 #12 #13
#14 and #15.
Someone meddles with my traffic and changes, while in transit, the
sequence number of the second packet from #11 to #789
How will the receiver behave upon receiving the packet with sequence
number #789 ? Will it wait a certain amount of time to see if the
packet #11 will arrive out of sequence before declaring #11 to be lost
and sending NAK to the sender ?
The received should, assuming that #789 is outside the window, just toss the data and pretend it didn't see it. If the data is inside the window, it might be stored for later usage.
How long will it wait before declaring #11 to be lost at sea ?
That depends. TCP/IP implementations can do this differently, but it is recommended that the average round trip time is measured, and that timeouts are set to about 2*rtt.
But this is all done by the sender. There is no NAK capability in TCP/IP.
base on what I read, the recipient will send an ack confirming it has
received all data intact until/including #10. (instead of sending an
actual "I haven't received #11").
Correct.
Once the sender has realised the recipient hasn't received #11, will the
sender then resend #11 and all subsequent packets ?
That depends on the implementation. It could do either.
Since TCP uses a sliding window, a lot of data can be outstanding at the time of a retransmission. If all data after the data not acknowledged is resent or not is not defined. However, it might be wise to back off, and not immediately start retransmitting all data again.
With windowing, will the sender end up stopping transmission at one
point, waiting for an ack ? Or will the "sorry I didn,t get #11"
realisation reach the sender before the sender has finished sending all
packets permitted in the sliding window ?
There is no NAK packet. TCP uses a sliding window to define which data can be sent and be outstanding before any ACK arrives. In addition, you also have a transmission window, which is used to do flow control. And this is normally all regulated by the amount of retransmissions you get.
And TCP don't acknowledge all data. ACK to a certain sequence number implies that all data up until that sequence number is acked.
The TCP flow control, congestion, retransmission, round trip calculation and back off algorithms are rather complex, and not easy to answer like this.
aka: will the data line become idle for some time, or will it remain
constantly in full use with packets flowing with retransmissions here
and there ?
No, TCP tries to be smart and not fill the net with retransmissions. But there is definitely some leeway for implementors to do things as they see fit as well, so it's not always possible to give a straight answer.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt@xxxxxxxxxx || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
.
- Follow-Ups:
- Re: TCPIP sequence number question
- From: JF Mezei
- Re: TCPIP sequence number question
- Prev by Date: Re: Happy 10 years of continuous virus free computing on OpenVMS alpha 7.1
- Next by Date: Re: Instructions setting up reverse LAT port on RSX11
- Previous by thread: Happy 10 years of continuous virus free computing on OpenVMS alpha 7.1
- Next by thread: Re: TCPIP sequence number question
- Index(es):
Relevant Pages
|
