FWD: RE: [e2e] Windows NT implementation of TCP

["Roy T. Fielding" <fi...@ebuilt.com>]

We might trip over this one at some point, so I figured it is worth
placing in the archive.

....Roy

Re: RE: [e2e] Windows NT implementation of TCP

[Bill Stoddard <bi...@wstoddard.com>]

> From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
> Sent: Thursday, July 26, 2001 10:00 PM
>
>
> > From: "Roy T. Fielding" <fi...@ebuilt.com>
> > Sent: Thursday, July 26, 2001 9:32 PM
> >
> >
> > > We might trip over this one at some point, so I figured it is worth
> > > placing in the archive.
> >
> > Bill Stoddard's efforts have been in exactly the _opposite_ direction :-)
> > Our aim is to reuse the socket, rather than a fast-disconnect and close.
>
> I stand corrected... we do accept the APR_SENDFILE_DISCONNECT_SOCKET option,
> and we do slam that closed on c->keepalive in the core.  Actually, we go a
> step further and TF_REUSE_SOCKET, which is sort of known not to really be
> well supported.
>

Actually I think the DISCONNECT|REUSE is a relatively well known and used optimization. I
have not observed any problems with it on NT 4.0. Never tested it on 2000 though. Reusing
the accept socket on AcceptEx provides a -really- big performance boost for non-keep alive
connections.  I wonder if the problem happens with the REUSE flag? in addition to the
DISCONNECT?  Will do some digging around...

Bill

Re: RE: [e2e] Windows NT implementation of TCP

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
Sent: Thursday, July 26, 2001 10:00 PM


> From: "Roy T. Fielding" <fi...@ebuilt.com>
> Sent: Thursday, July 26, 2001 9:32 PM
> 
> 
> > We might trip over this one at some point, so I figured it is worth
> > placing in the archive.
> 
> Bill Stoddard's efforts have been in exactly the _opposite_ direction :-)
> Our aim is to reuse the socket, rather than a fast-disconnect and close.

I stand corrected... we do accept the APR_SENDFILE_DISCONNECT_SOCKET option,
and we do slam that closed on c->keepalive in the core.  Actually, we go a
step further and TF_REUSE_SOCKET, which is sort of known not to really be
well supported.

Re: RE: [e2e] Windows NT implementation of TCP

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

From: "Roy T. Fielding" <fi...@ebuilt.com>
Sent: Thursday, July 26, 2001 9:32 PM


> We might trip over this one at some point, so I figured it is worth
> placing in the archive.

Bill Stoddard's efforts have been in exactly the _opposite_ direction :-)
Our aim is to reuse the socket, rather than a fast-disconnect and close.

But worth noting, thank you for forwarding this, Roy!



----- Original Message ----- 
From: "Christian Huitema" <hu...@windows.microsoft.com>
To: "Christian Huitema" <HU...@windows.microsoft.com>; "Sally Floyd" <fl...@aciri.org>; "Tan Koan-Sin" <fr...@csie.nctu.edu.tw>
Cc: <en...@postel.org>
Sent: Thursday, July 26, 2001 2:40 PM
Subject: RE: [e2e] Windows NT implementation of TCP 


> Last Monday, I sent a message announcing that a specific bug was fixed
> in Windows 2000 since SP1, and I was wrong:
> 
> > > While it it true that Windows NT and Windows 2000 both implement
> > > Fast Retransmit, in many cases, due to a bug in the implementation,
> > > Fast Retransmit is never invoked, and the TCP sender has to wait
> > > for a Retransmit Timeout to retransmit a lost packet.  This is
> > > discussed in more detail in the TBIT paper by Padhye and Floyd,
> > > available from "http://www.aciri.org/tbit/".
> > 
> > The bug occurred in Windows 2000, and has been fixed in the Service
> > Pack 1 issued in July 2000. The bug does not affect NT4 or XP, or any
> > version of W2K SP1 or greater.
> 
> It turns out that I had a "communication failure" with the developers in
> charge of correcting the said bug, which is not fixed in either W2K SP1
> or SP2. I am also told that it will be fixed shortly. 
> 
> To reproduce the bug (for those who care) you have to use a Microsoft
> specific socket command, "TransmitFile()" and you have to set the
> "TF_DISCONNECT" parameter to request an automatic disconnect at the end
> of the file transmission.
> 
> -- Christian Huitema 
>