Socket Issue

[BtySgtMajor]

Hey there,

I have a client/server architecture going here where my client creates an extended TcpClient object (I extended it so I could use an underlying socket since I need to specify the local port) every so-often and the polls the server for data. Now, when it does this polling, it's only sending back and forth short strings and small numbers. If it finds no "significant" data (that is, other than the short strings and numbers), it waits another interval, then polls again, etc.

Now, if it DOES find "significant" data, it reads it in, shuts down the connection and sockets; then my client deals with the data just fine, and sends back the results to the server using another extended TcpClient object to a different remote port. This works wonderfully, and then shuts down.

HOWEVER...The NEXT time it tries to poll with said extended TcpClient object, I get this SocketException:

"Only one usage of each socket address (protocol/network address/port) is normally permitted"

...and it's generated from the Connect method of the Socket. Now, I've set the following socket options:

- ReuseAddress
- DontLinger
- NoDelay

(I set them all to 1.)

The ONLY way this exception doesn't happen is if I wait 2 minutes or longer; this is unacceptable. Now, this would lead me to believe that it's an issue with data being left over in the stream or one of the sockets (local or remote) not being disposed of quick enough--but it's probably some combination of the two, since if the polling client finds no "significant" data, whenever it polls again, it creates the Socket again just fine. But the first time the "significant" data is picked up and processed, each subsequent poll will fail (ie. the socket will not connect). I've checked the "data available" properties and what not and they're all empty after I close the socket (I call "shutdown" first and then "close"). So I'm lost!

Can anyone lend me a hand here? This is really obnoxious.

Cheers,
Duncan

[Mike Hildner]

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

[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

[BtySgtMajor]

Well, I had originally planned on it being a service, but I had to scrap that idea since some of the code on the client side that processes the requests queued on the server cannot be run as a service. Oh well, guess I'll have to keep searching, unless others can suggest something else!

Thanks again for all your help.