Re: [C# .NET 2.0] Weird behaviour with Close method of TcpClient class

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Thu, 23 Jul 2009 08:39:03 -0700, Andreas Huber <ahd6974-spamboostorgtrap@xxxxxxxxx> wrote:

The problem I have with this code is that the server receives my
message approximatively 1 time out of 10.
But if I remove the finally block (NetworkStream and TcpClient
closing), the server receives my message every time.

What am I doing wrong here?
I'm pretty sure I have to close my connection and I read in some doc
that the underlying NetworkStream should also be closed.

You might try the LingerOption property:

http://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient.lingerstate.aspx

Unfortunately, at least according to the documentation, you can only _shorten_ the linger time for the socket using that property:

When the LingerTime property stored in the LingerState property
is set greater than the default IP protocol time-out, the default
IP protocol time-out will still apply and override.

I believe that the more general problem is that the original code is not calling Socket.Shutdown() before disposing/closing the stream and socket. I'm not an expert, but my recollection is that closing an open socket results in a "reset" of the connection (i.e. "RST" packet being sent) while a shutdown results in a "graceful closure" of the connection (i.e. "FIN" packet being sent). Some quick Googling seems to confirm this, with the additional wrinkle that the close initially causes a "FIN", but the network stack will send a "RST" if the other end tries to send any data.

So, it would be worthwhile to try a true graceful closure. Call Socket.Shutdown() after all the data is sent and then go ahead and wait for the full graceful closure, by reading from the socket until the end-of-stream is indicated (by a 0 byte read). As I understand it, that will ensure that both ends get a chance to read the data until they've both agree to close their sockets.

Pete
.

Relevant Pages

  • Re: Truncated data using .NET 3.5 sockets VS 2008
    ... neither the NS or the socket on either side is closed. ... a failure is the connection dropped and opened ... Your previous message seemed to say that you want to be able to close the NetworkStream without closing the Socket. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Async TCPClients
    ... must work out when using a synchronous loop is that one client should not ... What I wanted to do was to create a BinaryReader around a NetworkStream ... Only one client will use a any given socket at one time. ... just serialize the object and take the Stream's length as the length of the ...
    (microsoft.public.dotnet.general)
  • Re: basic question about NetworkStream( read/write, multiple thread)
    ... I remember there are 2 streams in Java, one for read, one for write. ... The fact is, the NetworkStream should basically just be delegating to the underlying Socket, and the Socket class _is_ thread safe. ...
    (microsoft.public.dotnet.languages.csharp)
  • Returning object from AsyncCallback called inside a threaded Infinite loop
    ... I'm working on a Peer2Peer app that uses an AsyncCallback to rerieve the ... delegate called 'OnReadComplete' and passes a StateObject with the connected ... public System.Net.Sockets.Socket socket; ... public NetworkStream networkStream; ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Im having problems with cryptography and sockets, help
    ... If the sender does not send 8192 bytes, the call to Read is going to ... I am> using blocking sockets, so I am aware that if the socket does not have ... But I know that it does receive> the data, and still it blocks, not the NetworkStream, but the CryptoStream> used to decrypt the data. ... > NetworkStream stream = clienteTcp.GetStream;> // Crear el stream criptográfico ...
    (microsoft.public.dotnet.languages.csharp)