I had a problem with too many connections After a few test i deducted the problem is with MY server. The fact that the server listening port was on the left side should have told me.
When running the same client code using a server on a different machine i dont get hundreds of ports opened. When my server on my local machine i get > 200 connects connecting to my listening port. I think i am handling clients wrong. My code is below with all non server and client code removed
{
TcpListener server = null;
server = new TcpListener(port);
server.Server.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, 1);
server.Start();
while (true)
{
var client = server.AcceptTcpClient();
using(var stream = client.GetStream()) {
...
stream.Read(...
...
stream.Write(...
} //using above should close this.
client.Close();
}
server.Stop();
}
I modified the code to use asynchronous connections and it locks up the 2nd time it does stream.Read just under the while (client.Connected)
server = new TcpListener(port);
server.Server.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, 1);
server.Start();
server.BeginAcceptTcpClient(new AsyncCallback(DoAcceptTcpClientCallback), server);
while (true)
Thread.Sleep(1000); //infinite loop for testing
public void DoAcceptTcpClientCallback(IAsyncResult ar)
{
Byte[] bytes = new Byte[1024 * 4];
TcpListener listener = (TcpListener)ar.AsyncState;
using (TcpClient client = listener.EndAcceptTcpClient(ar))
{
using (var stream = client.GetStream())
using (var ostream = new MemoryStream())
{
while (client.Connected)
{
int i;
while ((i = stream.Read(bytes, 0, bytes.Length)) == bytes.Length)
ostream.Write(bytes, 0, i);
ostream.Write(bytes, 0, i);
szresults = Func(ostream)
var obuf = Encoding.UTF8.GetBytes(szresults);
stream.Write(obuf, 0, obuf.Length);
}
}
client.Close();
}
}
You’re dealing with a connection within the same thread. That means you can only actively process a single connection at a time. The simplest approach is to pass the client to a new thread, and deal with it there.
Now that doesn’t scale hugely well – using fully asynchronous operations everywhere will allow you to serve the same number of clients using fewer threads – but in most cases it will work well enough, IME. It’s certainly where I’d go next.
Ideally you don’t want to create a new OS thread each time – it’s probably reasonable to use the system thread pool for this, so the thread can be reused after the connection has been completely handled. There are risks around filling up the OS thread pool, but I suspect that’s unlikely to bite you.
Finally, I’d put the
TcpClientinto ausingstatement to make sure you dispose of it even if something else fails. Of course, if you’re handing it over to another thread it should be that thread which immediately uses ausingstatement.