How to avoid TIME_WAIT state after closesocket() ?

[Hoffknecht]

After I close my non-blocking socket, netstat reports the socket with status
TIME_WAIT. I am positive, though, that there is no more data pending in the
send or receive buffer. I tried the SO_LINGER option, but I just can't get
rid of the TIME_WAIT state. Sourcecode is as follows:

linger Linger;
Linger.l_onoff=1; // set linger option
Linger.l_linger=2; // wait 2 seconds after closesocket
if ( setsockopt(MI->Socket,SOL_SOCKET, SO_LINGER,(const
char*)&Linger,sizeof(linger)) == SOCKET_ERROR )
// error handling

This section sits between the socket() and connect() calls. Later I close
the socket using shutdown(1), loop until recv() returns zero and then call
closesocket().

As per my understanding, winsock should give the socket 2 more seconds after
the closesocket() to finish all data transfer. I also tried all other LINGER
/ DONTLINGER combinations that I could think of.
I really appreciate help.
Marc

[Alun Jones]

In article <JrQf9.2564$621.4...@news20.bellglobal.com>, "Hoffknecht"

<Hoffk...@sympatico.ca> wrote:
>After I close my non-blocking socket, netstat reports the socket with status
>TIME_WAIT. I am positive, though, that there is no more data pending in the
>send or receive buffer. I tried the SO_LINGER option, but I just can't get
>rid of the TIME_WAIT state. Sourcecode is as follows:

TIME_WAIT is an appropriate state, and sockets will stay in that state for
2*MSL (4 minutes, usually) to ensure that there's no carry-over from previous
sessions into new sessions.

Read up on TCP, and find out what TIME_WAIT was designed to do. You will find
that it is not only natural, but _desirable_ to have sockets sitting in
TIME_WAIT for that length of time.

Alun.
~~~~

[Please don't email posters, if a Usenet response is appropriate.]
--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place | http://www.wftpd.com or email al...@texis.com
Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to
Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for XP/2000/NT.

[Chris Pearson]

TIME_WAIT isn't related to SO_LINGER. You can't (don't want to) avoid
TIME_WAIT as it's part of the TCP/IP standard. After you close a
connection, TCP won't reuse that connection (source addr/port, dest
addr/port combination) again for a while (2 * max segment lifetime (MSL) = 4
minutes) to be sure that any delayed packets from the old connection have
drained from the network. Otherwise, late arriving packets from the old
connection might appear to belong the the new connection and really mess
things up (by confusing segment sequence numbering).

As long as the client allows TCP to assign the source port number (by
binding to port zero), this shouldn't be a problem, since the new port
number designates a new connection. If client uses a constant source port,
it has to wait for old connection state to close.

-- CCP

"Hoffknecht" <Hoffk...@sympatico.ca> wrote in message
news:JrQf9.2564$621.4...@news20.bellglobal.com...

[Chris Pearson]

Woops, I see that Alan already said this (much more succintly too :-) ...

"Chris Pearson" <ChrisC...@acm.org> wrote in message
news:kYWf9.164$MR5.2...@news.uswest.net...

[William R. Epp]

If you want a hard close/really don't want the TIME_WAIT's use:
Linger.l_linger=0

[Chris Pearson]

> If you want a hard close/really don't want the TIME_WAIT's use:
> Linger.l_linger=0

... and don't call shutdown(), or call shutdown with SD_RECEIVE but not
SD_SEND or SD_BOTH. Your socket will always end up in TIME_WAIT if it
closes the connection first. (See TCP connection state diagram, RFC793,
page 23.) shutdown(SD_SEND/SD_BOTH) sends FIN, even when l_linger=0.

-- CCP

"William R. Epp" <res0...@verizon.net> wrote in message
news:lhr4oushpqdm917d0...@4ax.com...

[Alun Jones]

In article <3d85...@nntp0.pdx.net>, "Chris Pearson" <ChrisC...@acm.org>
wrote:

>> If you want a hard close/really don't want the TIME_WAIT's use:
>> Linger.l_linger=0
>

>.... and don't call shutdown(), or call shutdown with SD_RECEIVE but not

>SD_SEND or SD_BOTH. Your socket will always end up in TIME_WAIT if it
>closes the connection first. (See TCP connection state diagram, RFC793,
>page 23.) shutdown(SD_SEND/SD_BOTH) sends FIN, even when l_linger=0.

And again, I would like to point out that there is a purpose for TIME_WAIT.
Trying to avoid TIME_WAIT states without understanding what TIME_WAIT was
invented for, just because you want your "netstat" output to be shorter, is
usually a bad idea. Note that Internet Explorer is an example of one such
program, where the designers chose to reset connections, rather than leave
them in TIME_WAIT state, and as a result, every time an IE client downloads a
file from an FTP site, the FTP site registers it as an _aborted_ download.
That's just one example of why it's generally not a good idea to try and reset
connections to avoid TIME_WAIT.

It's been a long time (best part of a decade) since Microsoft's TCP stack was
adversely affected by lots of sockets in TIME_WAIT - sockets in TIME_WAIT do
no harm, and significant good. The OP needs to read some TCP books (or the
RFC) and learn why TIME_WAIT was implemented (what, you think it's some random
thing just to clutter up "netstat" output?), and what _all_ the consequences
are of avoiding that state.