Socket Issue

[BtySgtMajor]

When you say "shuts down the connection and sockets", what's the code you're using?

Also, what's your Socket.Connect code? Make sure to create a new Socket before calling .Connect and not re-use the old Socket instance.

Mike

The code to close the extended TCPClient is below.

Public Overloads Sub close()
        Try
            If (Me.Client.Connected) Then
                Me.Client.Shutdown(SocketShutdown.Both)
                Me.Client.Close()
            End If
 
            Me.Client = Nothing
            Me.Active = False
 
            ' double check
            If (m_theSocket.Connected) Then
                m_theSocket.Shutdown(SocketShutdown.Both)
                m_theSocket.Close()
            End If
 
            m_theSocket = Nothing
        Catch e As Exception
            el.WriteEntry("Client: Error closing connection - " & e.Message & vbCrLf & e.StackTrace)
        End Try
    End Sub

As for the connecting, after using an instance of my extended TCPClient once, I call the code above (its close() method), and then set the instance to Nothing. When I need it again for the second time, I create a new instance. The socket associated with the extended TCPClient is a member variable and is "new"'d with each call to connect() (and as you can see above, when close() is called, the socket is shutdown, closed, and set to Nothing).

I believe this is an acceptable way of doing things. It's the whole "two minutes" thing. I've read that Microsoft has some faulty port handling/releasing where it takes up to two minutes to clean up and release the port if its moved a fair bit of data, but that might just be conjecture. Any help that can be rendered would be most appreciated.

Cheers,
Duncan

[Mike Hildner]

Since you're newing up the TcpClient class every time, the only thing I can think to do is to close the socket's stream as well as closing the socket. From the MSDN topic TcpClient.Close

The Close method marks the instance as disposed but does not close the TCP connection. Calling this method does not release the NetworkStream that is used to send and receive data. You must call the Close method to close the stream and the TCP connection.

If that doesn't work, you might be right about something outside of your control. Maybe you can keep the connection open rather than establishing a new connection each time? FWIW, that's what I usually do, and I just try to reconnect if the connection gets broken.

Mike

[BtySgtMajor]

Hmm, that's interesting. I bet that has something to do with it. I took out the Networkstream close() call because it shuts down the underlying socket since it owns it and it doesn't give me a chance to call shutdown(). I'll setup a call to shutdown() and I'll let you know.

Thanks again!

[BtySgtMajor]

And sadly, it didn't fix it. Just so you know, when I'm shutting down things, this is the order in which I'm doing it:

' for both the client and server code
theSocket.shutdown
theStream.close
theStream = Nothing

theSocket.close ' just in case
theSocket = Nothing

Also, the reason why I don't just keep the socket open is because this is a distributed application, ie. it's possible to have an unknown number of clients that will need to connect to the server, and I only have so many threads that handle the requests on the server for the given port. I need to free up the threads once they're done handling the client's request for that reason (to service other requests).

Thoughts?

Cheers,
Duncan

[Mike Hildner]

Hmm, that sucks.

Is it the client code or the server code that's giving you trouble? If it's the client, can you connect with a different client port? Are you specifying the port? The client port that is.

Normally my apps have a server port defined for the client to connect to, but I don't force the client to use a particular port on it's end. So it gets assigned an available port automatically.

Mike

[BtySgtMajor]

It's the client code that's giving me the exception when I try to connect using the socket created on the client's end. The reason for using a socket instead of the base TcpClient class was because I wanted to force the client to use a specific outbound port; the reason for doing so is I'm trying to be mindful that this application will probably be used in a lot of cases behind a (probably corporate) firewall that probably filters outgoing ports. Ergo, if I can keep the force the outbound communication to one port, it's less of a security risk than opening up two, and I can possibly use something common like port 80.

I can connect with any client port I specify. This error still occurs, which makes sense, since the first time I get the "significant" data through, it works; it's the subsequent connections that fail.

Thinking about my code again, after the first client socket receives the main data, it closes, my code handles the data, opens a new socket (after binding, yes) using the same local port, sends back the response, and closes the socket. Any subsequent connection to the local port fails. I guess the problem is somewhere within the code that sends back the response to the server after that second opening. I'm closing everything down though, so I'm at a bit of a loss. Could there be something else fundamental I'm missing from that second part?

[Mike Hildner]

Sorry, I'm out of ideas. Never ran into that as my socket stuff doesn't force the client to use a particular port.

Not a solution, but can you ditch the whole socket business and use a web service instead? Given what you need to do, a web service seems perfect.

Mike