Socket Issue

[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.