I have been thinking about what is the right way of set up a TCP server by using asynchronous programming.
Usually I would spawn a thread per incoming request, but I would like to do the most of the ThreadPool, so when connections are idle, there are no blocked threads.
First I would create the listener and start to accept clients, in this case, in a Console app:
static void Main(string args)
CancellationTokenSource cancellation = new CancellationTokenSource();
var endpoint = new IPEndPoint(IPAddress.Parse("127.0.0.1"), 8001);
TcpListener server = new TcpListener(endpoint);
var task = AcceptTcpClients(server, cancellation.Token);
static async Task AcceptTcpClients(TcpListener server, CancellationToken token)
var ws = await server.AcceptTcpClientAsync();
Task.Factory.StartNew(async () =>
while (ws.IsConnected && !token.IsCancellationRequested)
String msg = await ws.ReadAsync();
if (msg != null)
await task; in your
Main won't compile; you'll have to use
task.Wait(); if you want to block on it.
Also, you should use
Task.Run instead of
Task.Factory.StartNew in asynchronous programming.
Creating new Task does not necessarily mean new thread, but is this the right way?
You certainly can start up separate tasks (using
Task.Run). Though you don't have to. You could just as easily call a separate
async method to handle the individual socket connections.
There are a few problems with your actual socket handling, though. The
Connected property is practically useless. You should always be continuously reading from a connected socket, even while you're writing to it. Also, you should be writing "keepalive" messages or have a timeout on your reads, so that you can detect half-open situations. I maintain a TCP/IP .NET FAQ that explains these common problems.
I really, strongly recommend that people do not write TCP/IP servers or clients. There are tons of pitfalls. It would be far better to self-host WebAPI and/or SignalR, if possible.