Forcing tcp client socket to close and not go into CLOSE_WAIT state

  • Thread starter Thread starter Claire
  • Start date Start date
C

Claire

I'm trying to debug my network application ie I want to check my error
handling when the connection is broken.
Im using 127.0.0.1 as the connection address.
Unfortunately, the client socket goes into a CLOSE_WAIT state ad infinitum
and never closes fully until my client and server applications shut down.
Ive disabled lingeroptions.

Is there anything else easy that i can do to force the loopback to close
immediately?

thanks
 
aSocket.Shutdown(SocketShutdown.Both);
aSocket.Close();
if (aSocket.Connected) {
Console.WriteLine("Winsock error: " +
Convert.ToString(System.Runtime.InteropServices.Marshal.GetLastWin32Error())
);
}

AFAIK
CLOSE_WAIT Indicates passive close. Server just received first FIN from a
client.

Also the issue may occur when the client properly closed the connection (FIN
has been sent), but the server still has its socket open. This could be the
result of one instance (among all threads or processes) of the socket not
being closed.

Also you can use 'sniffer' tool to see how your connection is being closed
in the low level...
 
It is possible to similar to a System.Net.Sockets.TcpClient where Im unable
to get at the socket itself?
Im also using a System.Net.Sockets.NetworkStream attached to this.

private System.Net.Sockets.TcpClient myClient;

private System.Net.Sockets.NetworkStream myStream;

public void Disconnect()

{

if (myClient == null) return;

LogDebug("Disconnect", "Closing socket");

// closing stream also closes socket

myStream.Close();

myClient = null;

myStream = null;

}
 
In the code sample you miss myClient.Close();

In order to access the underlying socket object you have to inherit from
TcpClient class and override its Client property...
 
Unfortunately, the client socket goes into a CLOSE_WAIT state ad
infinitum
and never closes fully until my client and server applications shut down.
Click to expand...

From the RFC http://iptables-tutorial.frozentux.net/other/rfc793.txt:

CLOSE-WAIT - represents waiting for a connection termination request
from the local user.

Looks like either your client or server application is not closing its
socket properly. You'd have to post a working sample for anyone to
examine why, though.
Ive disabled lingeroptions.
Click to expand...
In a normal scenario, why change lingeroptions?

Greetings,
Wessel
 
Hi Wessel

Looks like either your client or server application is not closing its
socket properly. You'd have to post a working sample for anyone to
examine why, though.
Click to expand...

private System.Net.Sockets.TcpClient myClient;

private System.Net.Sockets.NetworkStream myStream;

public TCPClientDriver(string Address, int PortNum)

{

string fnName = "Constructor";

LogDebug(fnName, "Attempting to create and open TCP client");

try

{

myClient = new System.Net.Sockets.TcpClient(Address, PortNum);

myStream = myClient.GetStream();

LogDebug(fnName, "Success");

InitializedOK = true;

}

catch(Exception e)

{

WinsockError = e.Message;

LogDebug(fnName, "Failed");

LogException(fnName, e);

}

}//public TCPClientDriver(string Address, int PortNum)

In a normal scenario, why change lingeroptions?
Click to expand...
Only in a desperate random attempt to get the socket to close fully for
debug purposes.
 
private System.Net.Sockets.TcpClient myClient;
private System.Net.Sockets.NetworkStream myStream;

public TCPClientDriver(string Address, int PortNum)

{

string fnName = "Constructor";

LogDebug(fnName, "Attempting to create and open TCP client");

try

{

myClient = new System.Net.Sockets.TcpClient(Address, PortNum);

myStream = myClient.GetStream();

LogDebug(fnName, "Success");

InitializedOK = true;

}

catch(Exception e)

{

WinsockError = e.Message;

LogDebug(fnName, "Failed");

LogException(fnName, e);

}

}//public TCPClientDriver(string Address, int PortNum)
Click to expand...
That's the client part of creating the socket, right? Do you have a
sample of how you close the socket client-side? Are you in control of the
server too?
Only in a desperate random attempt to get the socket to close fully for
debug purposes.
Click to expand...
Right. Should be possible without lingeroption, tho.

Greetings,
Wessel
 
That's the client part of creating the socket, right? Do you have a
sample of how you close the socket client-side? Are you in control of the
server too?
Click to expand...
I'm not trying to close the server. It's the server's handling of loss of
network client (error handling) that Im trying to test during my file
transfer protocol.
The above code shows samples of both creating/opening and closing the client
socket. Thas is, I've included the constructor and the Disconnect function.
There's not much to go wrong really lol.
Yes. Im writing both sides of the code. At this early stage, the client runs
in the same process as the application start, no threading. The server
generates a new thread for each connection. Each thread synchronously
monitors whether data is available. Ive put no code in to disconnect the
server yet.

Right. Should be possible without lingeroption, tho.
Click to expand...

Fair enough :)

thank you wessel
 
I'm not trying to close the server. It's the server's handling of loss of
network client (error handling) that Im trying to test during my file
transfer protocol.
Click to expand...
Well that explains it. The RFC says:

WAIT_CLOSE represents waiting for a connection termination request
from the local user.

If you pull out the network connection, depending on how you do it, the
TCP endpoints may survive for when the connection comes back up. In your
case, the WAIT_CLOSE state says that one of the programs has initiated TCP
shutdown. The followup packet to acknowledge shutdown has not arrived,
but the server waits for approx 2 minutes for it.

This doesn't mean the server is "occupied" during this period. Other
clients can connect to the same server socket (but you knew that already,
of course. :P)

Anyways consider looking at the RFC:
http://iptables-tutorial.frozentux.net/other/rfc793.txt

Good luck,
Wessel
 
Back
Top