Chris McKenzie's Blog

Every socket has four pieces of information to make it unique: server IP address, server port, client IP address, client port. If I look at netstat right now, I see IE opened two connections to your web server on port 80, one from port 4766, and one from port 4767. I have two connections to the same port on your server, but since the client ports are different the communication works. Likewise, I’m sure weblogs.asp.net has many connections opened on port 80, but each one will come from a different client ip / client port combination.

You can only listen on a port from one socket at a time, but the Accept method will return a new instance of the Socket class for each client.

Am I making any sense?

One other thing to note is that the application has to be multithreaded in order to handle multiple connections. You can do something as dirty as accepting the connection and forking, then having the child process deal with the new connection and the parent process go back to waiting for a new connection. Or, you could use actual threads for better memory and process management. But basically, a single instance of the application running can only do one thing at a time, so if it is working with the new client, it can't be listening for new connections, so in order to support multiple connections, you always need to have one process listening.

As far as threading in .NET, I'm not sure. My experience in socket programming and threading is from the Unix realm.

To further clarify Ken's idea: start with your main thread. The entire purpose of this main thread is to listen on the incoming port. As soon as a request arrives, fire off another worker thread to do process the request. This is typically a very fast an efficient action so the main thread can immediately get back to listening for further requests. If you can, keep your worker threads as autonomous as possible; interact with the main thread as little as possible. Depending on your bandwidth requirements, it may be necessary to increase process priority or, for very high throughput, move to an SMP system. There are plenty of examples out there on multithreading using .NET. Good luck.

Thanks guys. That was exactly the information I'm looking for. I just ordered the multi-threading book, so by the time I need this to work with multiple connections, I'll have it. Now at least I know that what I need to do can be done--and as NBC so often reminds us <grin> "Knowing is half the battle!"