Subject: RE: corruption in socket layer?
From: [email-masked] (Colin Peters)

9 Oct 1997 19:48:54 -0700
Message-ID: <01BCD4DF.0C74ADA0.cygnus.gnu-win32@gbird0>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: "'Khosla, Deepak'" <[email-masked]>
Cc: "'GNU-Win32'" <[email-masked]>

Khosla, Deepak[SMTP:[email-masked]] wrote:
>We ran into a similar (yet different) problem - with WINSOCK you 
>cannot guarantee that on a close all the data is flushed. You better 
>do some application level handshaking. We saw that even if we did a 
>close with a timeout period, the lower level never told you whether 
>the timeout expired or whether the data was actually sent. It appears 
>that the state goes to FIN_WAIT even though a FIN has not been sent 
>out and then a close is successful!. The condition we saw this in was 
>if the remote had set the window size to zero while at the same time 
>we had only enough data left that would fit in the internal TCP 
>buffers. We would do a close, it would return successful and we would 
>go on trying to establish a new connection to the same remote and it 
>would send a reset back since from its point of view, the previous 
>session was alive.
>
>The bug was reported to MS a few months back - no response other than 
>that's how Winsock works :-)

I don't want to start any big arguments, but, if you are using Winsock,
and according to how I read the documentation I have available to me,
that *is* how Winsock works... which is not to say that's good but...
Even if you use setsockopt to turn off SO_DONTLINGER (which is on by
default) and set a SO_LINGER timeout there is no guarantee that the
data waiting in the TCP buffer has been sent when closesocket returns.
I would expect closesocket to return WSAETIMEDOUT in such a case, but
the documentation doesn't say that it should. Perhaps a newer version
of the spec says that it will and in order to force a close you have
to set SO_LINGER l_linger option to zero, but that type of thing
isn't mentioned anywhere in the spec I have. It just says that
closesocket waits until the timeout is up (if any) and then closes the
connection, even if data is waiting (and obviously one shouldn't send
a FIN if there is TCP data waiting to be sent... well, I guess that's
obvious). If the WSAETIMEOUT (or some other) error was used, then at
least we could be sure that the data got through if we didn't get a
timeout. The man pages on the Sun here aren't clear on this point
either (they don't indicate that a close will return ETIMEDOUT in such
a case, or ever, and the setsockopt page does not discuss what happens
exactly when the timeout expires for a SO_LINGER set socket when it is
closed).

From Winsock's (or sockets') point of view when the application calls
close it is saying (I think) "I am finished with this connection
completely, free up the resources associated with it." You can't do
anything with a socket after closesocket returns, but it would still
be worth it to return a timeout error, so that applications could
notify the user of improperly terminated connections. However, the
specs don't seem to say anything about it. The way it is I suppose
it is correct to say that applications must do some final handshaking
to ensure that data transfer is complete, but I don't think it is,
directly, the implementation's fault.

Colin.

-- Colin Peters - Saga Univ. Dept. of Information Science
-- [email-masked] - finger for PGP public key
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html
-- http://www.geocities.com/Tokyo/Towers/6162/

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".