TcpClient dispose order

Question

I am writing a network layer on top of TCP and I am facing some troubles during my UnitTest phase.

Here is what I'm doing (My library is composed of multiple classes but I only show you the native instructions causing my problems, to limit the size of the post):

private const int SERVER_PORT = 15000;
private const int CLIENT_PORT = 16000;
private const string LOCALHOST = "127.0.0.1";

private TcpClient Client { get; set; }
private TcpListener ServerListener { get; set; }
private TcpClient Server { get; set; }

[TestInitialize]
public void MyTestInitialize()
{
    this.ServerListener = new TcpListener(new IPEndPoint(IPAddress.Parse(LOCALHOST), SERVER_PORT));
    this.Client = new TcpClient(new IPEndPoint(IPAddress.Parse(LOCALHOST), CLIENT_PORT));

    this.ServerListener.Start();
}

// In this method, I just try to connect to the server
[TestMethod]
public void TestConnect1()
{
    var connectionRequest = this.ServerListener.AcceptTcpClientAsync();

    this.Client.Connect(LOCALHOST, SERVER_PORT);

    connectionRequest.Wait();

    this.Server = connectionRequest.Result;
}

// In this method, I assume there is an applicative error within the client and it is disposed
[TestMethod]
public void TestConnect2()
{
    var connectionRequest = this.ServerListener.AcceptTcpClientAsync();

    this.Client.Connect(LOCALHOST, SERVER_PORT);

    connectionRequest.Wait();

    this.Server = connectionRequest.Result;

    this.Client.Dispose();
}

[TestCleanup]
public void MyTestCleanup()
{
    this.ServerListener?.Stop();
    this.Server?.Dispose();
    this.Client?.Dispose();
}

First of all, I HAVE TO dispose the server first if I want to connect earlier to the server on the same port from the same endpoint:

If you run my tests like this, it will run successfully the first time. The second time, it will throw an exception, in both tests, on the Connect method, arguing the port is already in use.

The only way I found to avoid this exception (and to be able to connect on the same listener from the same endpoint) is to provoke a SocketException within the Server by sending bytes to the disposed client twice (on the first sending, there is no problem, the exception is thrown only on the second sending).

I don't even need to Dispose the Server if I provoke an Exception ...

Why is the Server.Dispose() not closing the connection and freeing the port ??? Is there a better way to freeing the port than by provoking an Exception ?

Thanks in advance.

(Sorry for my English, I am not a native speaker)

---

Here is an example within a main fonction, to be checkout more easily:

private const int SERVER_PORT = 15000;
private const int CLIENT_PORT = 16000;
private const string LOCALHOST = "127.0.0.1";

static void Main(string[] args)
{
    var serverListener = new TcpListener(new IPEndPoint(IPAddress.Parse(LOCALHOST), SERVER_PORT));
    var client = new TcpClient(new IPEndPoint(IPAddress.Parse(LOCALHOST), CLIENT_PORT));

    serverListener.Start();

    var connectionRequest = client.ConnectAsync(LOCALHOST, SERVER_PORT);

    var server = serverListener.AcceptTcpClient();

    connectionRequest.Wait();

    // Oops, something wrong append (wrong password for exemple), the client has to be disposed (I really want this behavior)
    client.Dispose();

    // Uncomment this to see the magic happens
    //try
    //{
        //server.Client.Send(Encoding.ASCII.GetBytes("no problem"));
        //server.Client.Send(Encoding.ASCII.GetBytes("oops looks like the client is disconnected"));
    //}
    //catch (Exception)
    //{ }

    // Lets try again, with a new password for example (as I said, I really want to close the connection in the first place, and I need to keep the same client EndPoint !)
    client = new TcpClient(new IPEndPoint(IPAddress.Parse(LOCALHOST), CLIENT_PORT));

    connectionRequest = client.ConnectAsync(LOCALHOST, SERVER_PORT);

    // If the previous try/catch is commented, you will stay stuck here, 
    // because the ConnectAsync has thrown an exception that will be raised only during the Wait() instruction
    server = serverListener.AcceptTcpClient();

    connectionRequest.Wait();

    Console.WriteLine("press a key");
    Console.ReadKey();
}

You may need to restart Visual Studio (or wait some time) if you trigger the bug and the program refuse to let you connect.

Answer 1

Your port is already in use. Run netstat and see. You'll find ports still open in the TIME_WAIT state.

Because you have not gracefully closed the sockets, the network layer must keep these ports open, in case the remote endpoint sends more data. Were it to do otherwise, the sockets could receive spurious data meant for something else, corrupting the data stream.

The right way to fix this is to close the connections gracefully (i.e. use the Socket.Shutdown() method). If you want to include a test involving the remote endpoint crashing, then you'll need to handle that scenario correctly as well. For one, you should set up an independent remote process that you can actually crash. For another, your server should correctly accommodate the situation by not trying to use the port again until an appropriate time has passed (i.e. the port is actually closed and is no longer in TIME_WAIT).

On that latter point, you may want to consider actually using the work-around you've discovered: TIME_WAIT involves the scenario where the status of the remote endpoint is unknown. If you send data, the network layer can detect the failed connection and effect the socket cleanup earlier.

For additional insights, see e.g.:
Port Stuck in Time_Wait
Reconnect to the server
How can I forcibly close a TcpListener
How do I prevent Socket/Port Exhaustion?

(But do not use the recommendation found among the answers to use SO_REUSEADDR/SocketOptionName.ReuseAddress…all that does is hide the problem, and can result in corrupted data in real-world code.)

Answer 2

TCP socket hang around in TIME_WAIT after closing and shutdown. The .Net way to get the socket back is to use:

 
_socket.Client.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);    // Reuse addresses to prevent TIME WAIT