I try to connect a ftp server 10.71.45.111, and send and receive the
following packages:

17:42:25.585644 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: S
3202375017:3202375017(0) win 65535 <mss 1460,nop,nop,sackOK>
17:42:25.586886 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: S
127580257:127580257(0) ack 3202375018 win 16384 <mss
1460,nop,nop,sackOK>
17:42:25.586924 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 1 win
65535
17:42:25.589736 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: .
1:1461(1460) ack 1 win 65535
17:42:25.589873 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: .
1461:2921(1460) ack 1 win 65535
17:42:25.589904 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 2921
win 65535
17:42:25.591364 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: P
2921:3885(964)ack1 win 65535
17:42:25.591414 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 3885
win 64571
17:42:25.633654 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: P 1:13(12)
ack 3885 win 64571
17:42:25.634487 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: P
3885:3919(34) ack 13 win 65523
17:42:25.635847 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: P 13:25(12)
ack 3919 win 64537
17:42:25.833475 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: . ack 25 win
65511
17:42:28.636685 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: P
3919:3967(48) ack 25 win 65511
17:42:28.636734 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: F
3967:3967(0) ack 25 win 65511
17:42:28.636775 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 3968
win 64489
17:42:28.637031 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: R 25:25(0)
ack 3968 win 0

The ftp server shows that there are too many users logging in, and
closed the TCP connection.
But to my surprise, when the ack package returns, it still shows the
TCP windows is 64489. Why the TCP windows suddenly becomes 0?
What makes me more surprising is that I have no such problem when I
connect other ftp servers.

In article <1149047776.011576.48380@i39g2000cwa.googlegroups. com>,
"Zheng Da" <zhengda1936@gmail.com> wrote:

> I try to connect a ftp server 10.71.45.111, and send and receive the
> following packages:
>
> 17:42:25.585644 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: S
> 3202375017:3202375017(0) win 65535 <mss 1460,nop,nop,sackOK>
> 17:42:25.586886 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: S
> 127580257:127580257(0) ack 3202375018 win 16384 <mss
> 1460,nop,nop,sackOK>
> 17:42:25.586924 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 1 win
> 65535
> 17:42:25.589736 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: .
> 1:1461(1460) ack 1 win 65535
> 17:42:25.589873 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: .
> 1461:2921(1460) ack 1 win 65535
> 17:42:25.589904 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 2921
> win 65535
> 17:42:25.591364 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: P
> 2921:3885(964)ack1 win 65535
> 17:42:25.591414 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 3885
> win 64571
> 17:42:25.633654 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: P 1:13(12)
> ack 3885 win 64571
> 17:42:25.634487 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: P
> 3885:3919(34) ack 13 win 65523
> 17:42:25.635847 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: P 13:25(12)
> ack 3919 win 64537
> 17:42:25.833475 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: . ack 25 win
> 65511
> 17:42:28.636685 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: P
> 3919:3967(48) ack 25 win 65511
> 17:42:28.636734 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: F
> 3967:3967(0) ack 25 win 65511
> 17:42:28.636775 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 3968
> win 64489
> 17:42:28.637031 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: R 25:25(0)
> ack 3968 win 0
>
> The ftp server shows that there are too many users logging in, and
> closed the TCP connection.
> But to my surprise, when the ack package returns, it still shows the
> TCP windows is 64489. Why the TCP windows suddenly becomes 0?
> What makes me more surprising is that I have no such problem when I
> connect other ftp servers.

The window size doesn't matter in a RST packet, since you can't send any
more on a connection after receiving this.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin wrote:
>
> The window size doesn't matter in a RST packet, since you can't send any
> more on a connection after receiving this.

I know, and I am just surprised.
But I have got other situations that the TCP window becomes 0 and the
connection is closed forcedly by a RST packet.
So I want to know the reason.

In general (ignoring the case of the segments with RST set) if the
window field of the header is 0 it means the receiver's "SO_SNDBUF" is
full. That will happen when the receiver does not recv data from the
socket as fast or faster than the data arrives. So, the window goes
to zero to stop the sender from sending so the receiver has a chance
to catch-up. All basic TCP flow-control stuff

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

But in this case, it is impossible for the ftp server to send so much
data in the ftp control connection that the tcp window goes to 0.
Do all tcp connections share one buffer, or each of them has its own?

Rick Jones wrote:
> In general (ignoring the case of the segments with RST set) if the
> window field of the header is 0 it means the receiver's "SO_SNDBUF" is
> full. That will happen when the receiver does not recv data from the
> socket as fast or faster than the data arrives. So, the window goes
> to zero to stop the sender from sending so the receiver has a chance
> to catch-up. All basic TCP flow-control stuff
>

In article <1149131569.253368.208240@f6g2000cwb.googlegroups. com>,
"Zheng Da" <zhengda1936@gmail.com> wrote:

> Rick Jones wrote:
> > In general (ignoring the case of the segments with RST set) if the
> > window field of the header is 0 it means the receiver's "SO_SNDBUF" is
> > full. That will happen when the receiver does not recv data from the
> > socket as fast or faster than the data arrives. So, the window goes
> > to zero to stop the sender from sending so the receiver has a chance
> > to catch-up. All basic TCP flow-control stuff
> >
> But in this case, it is impossible for the ftp server to send so much
> data in the ftp control connection that the tcp window goes to 0.
> Do all tcp connections share one buffer, or each of them has its own?
>

Rick was just answering your general question about why the window goes
to zero. It's unlikely that this would happen to the FTP control
connection, for the reason you state, but it could depend on the TCP
stack. Even though each connection may have its own buffer size, if
there are enough connections the kernel could simply run out of memory
and not be able to accommodate all the buffers.

Do you have an example where this actually happens to the control
connection?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin wrote:
> Rick was just answering your general question about why the window goes
> to zero. It's unlikely that this would happen to the FTP control
> connection, for the reason you state, but it could depend on the TCP
> stack. Even though each connection may have its own buffer size, if
> there are enough connections the kernel could simply run out of memory
> and not be able to accommodate all the buffers.
>
> Do you have an example where this actually happens to the control
> connection?
>
In my first letter, I show an example that I tried to log in a ftp
server.
Maybe I should show it again.
17:42:25.585644 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: S
3202375017:3202375017(0) win 65535 <mss 1460,nop,nop,sackOK>
17:42:25.586886 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: S
127580257:127580257(0) ack 3202375018 win 16384 <mss
1460,nop,nop,sackOK>
17:42:25.586924 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 1 win
65535
17:42:25.589736 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: .
1:1461(1460) ack 1 win 65535
17:42:25.589873 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: .
1461:2921(1460) ack 1 win 65535
17:42:25.589904 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 2921
win 65535
17:42:25.591364 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: P
2921:3885(964)ack1 win 65535
17:42:25.591414 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 3885
win 64571
17:42:25.633654 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: P 1:13(12)
ack 3885 win 64571
17:42:25.634487 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: P
3885:3919(34) ack 13 win 65523
17:42:25.635847 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: P 13:25(12)
ack 3919 win 64537
17:42:25.833475 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: . ack 25 win
65511
17:42:28.636685 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: P
3919:3967(48) ack 25 win 65511
17:42:28.636734 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: F
3967:3967(0) ack 25 win 65511
17:42:28.636775 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 3968
win 64489
17:42:28.637031 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: R 25:25(0)
ack 3968 win 0

Zheng Da <zhengda1936@gmail.com> wrote:
> In my first letter, I show an example that I tried to log in a ftp
> server.
> Maybe I should show it again.
> 17:42:25.585644 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: S
> 3202375017:3202375017(0) win 65535 <mss 1460,nop,nop,sackOK>
> 17:42:25.586886 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: S
> 127580257:127580257(0) ack 3202375018 win 16384 <mss
> 1460,nop,nop,sackOK>
> 17:42:25.586924 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 1 win
> 65535
> 17:42:25.589736 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: .
> 1:1461(1460) ack 1 win 65535
> 17:42:25.589873 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: .
> 1461:2921(1460) ack 1 win 65535
> 17:42:25.589904 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 2921
> win 65535
> 17:42:25.591364 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: P
> 2921:3885(964)ack1 win 65535
> 17:42:25.591414 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 3885
> win 64571
> 17:42:25.633654 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: P 1:13(12)
> ack 3885 win 64571
> 17:42:25.634487 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: P
> 3885:3919(34) ack 13 win 65523
> 17:42:25.635847 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: P 13:25(12)
> ack 3919 win 64537
> 17:42:25.833475 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: . ack 25 win
> 65511
> 17:42:28.636685 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: P
> 3919:3967(48) ack 25 win 65511
> 17:42:28.636734 IP 10.71.45.111.21 > mircosof-1d9d0f.3211: F
> 3967:3967(0) ack 25 win 65511
> 17:42:28.636775 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: . ack 3968
> win 64489
> 17:42:28.637031 IP mircosof-1d9d0f.3211 > 10.71.45.111.21: R 25:25(0)
> ack 3968 win 0

The only place I see a zero window here is on the RST segment which I
think Barry already addressed as being generally uninteresting since a
RST means the connection is dead anyway.

rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

So do you mean the window of a RST segment is always zero?

Rick Jones wrote:
>
> The only place I see a zero window here is on the RST segment which I
> think Barry already addressed as being generally uninteresting since a
> RST means the connection is dead anyway.
>
> rick jones
> --
> Wisdom Teeth are impacted, people are affected by the effects of events.
> these opinions are mine, all mine; HP might not want them anyway...
> feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

I have a question: which causes the RST segment, the zero window or
some other segments?

Rick Jones wrote:
>
> The only place I see a zero window here is on the RST segment which I
> think Barry already addressed as being generally uninteresting since a
> RST means the connection is dead anyway.
>
> rick jones
> --
> Wisdom Teeth are impacted, people are affected by the effects of events.
> these opinions are mine, all mine; HP might not want them anyway...
> feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Zheng Da <zhengda1936@gmail.com> wrote:
> So do you mean the window of a RST segment is always zero?

I (and Barry) mean that the window in an RST segment is a don't care
because it will be ignored by any correctly written TCP stack. RST
means the connection is toast, send no more data. So, the size of the
window is moot.

rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Zheng Da <zhengda1936@gmail.com> wrote:
> I have a question: which causes the RST segment, the zero window or
> some other segments?

Let go of the window in the RST segment already It just doesn't
matter.

RST's can be cause by any number of things. Among them are:

*) retransmission timeout
*) protocol violation
*) segment arriving for which there is no matching TCP endpoint
*) idiotic use of abortive close() by brain-dead application programmers

rick jones
--
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

In article <va3gg.1464$JX5.1107@news.cpqcorp.net>,
Rick Jones <rick.jones2@hp.com> wrote:

>> I have a question: which causes the RST segment, the zero window or
>> some other segments?
>
>Let go of the window in the RST segment already It just doesn't
>matter.
>
>RST's can be cause by any number of things. Among them are:
> ...

Yes, but I wonder if it is understood that an RST segment is any TCP
segment whose header has the RST flag bit set, often indicated by
packet tracers with nothing more than an 'R'.


Vernon Schryver vjs@rhyolite.com

In article <1149217123.095222.230590@y43g2000cwc.googlegroups .com>,
"Zheng Da" <zhengda1936@gmail.com> wrote:

>
> Rick Jones wrote:
> >
> > The only place I see a zero window here is on the RST segment which I
> > think Barry already addressed as being generally uninteresting since a
> > RST means the connection is dead anyway.
> So do you mean the window of a RST segment is always zero?

On that particular OS, probably. Why do you care?

P.S. Please stop top-posting, it destroys the order of the conversation.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***