proper Cancellation?

Currently the app freezes for seconds when clicking the red X of the console window – which is nearly the same as a task kill. How to stop Socket.AcceptAsync from “blocking” infinitely?

Further:

• what about proper disposing of IDisposables?
• async Main method does not contain a single await … why not await ProcessLinesAsync?
• no .editorconfig so first contact with ctrl+k-d reformats everything

[gfoidl]

Keep in mind that this is an introductionary sample, not one that can and should be used in production directly. It’s more or less a demo to get your feets wet with pipelines. If this demo would be productized, then it would be too big for an intro.

Currently the app freezes for seconds when clicking the red X of the console window

In this demo there is no unbind on the socket, etc. and nothing that stops the accept-loop https://github.com/davidfowl/TcpEcho/blob/07ad4df181151850974219b8ebf434eee37778a4/src/Program.cs#L22-L26 You could run this server in a generic host, and leverage cancellation as well as proper disposing. But, as said before, this would be too much for an intro…

async Main method does not contain a single await

Here it is: https://github.com/davidfowl/TcpEcho/blob/07ad4df181151850974219b8ebf434eee37778a4/src/Program.cs#L24

… why not await ProcessLinesAsync?

Imagine https://github.com/davidfowl/TcpEcho/blob/07ad4df181151850974219b8ebf434eee37778a4/src/Program.cs#L25 would be written as

await ProcessLinesAsync(socket);

what would happen?

1. The accept-loop asynchronously awaits a client-connection https://github.com/davidfowl/TcpEcho/blob/07ad4df181151850974219b8ebf434eee37778a4/src/Program.cs#L24
2. ProcessLinesAsync is “started” for that client, the accept-loop asynchronously awaits ProcessLinesAsync to be completed
3. ProcessLinesAsync will complete only when reading and writing are done https://github.com/davidfowl/TcpEcho/blob/07ad4df181151850974219b8ebf434eee37778a4/src/Program.cs#L37
4. goto point 1

So this would handle one client at a time and when the one is done, the next client is handled. Not very scalable.

With the implementation as is, the following happens:

1. The accept-loop asynchronously awaits a client-connection
2. ProcessLinesAsync is “started” for that client, the returning Task is thrown away, because we don’t want to await it
3. goto point 1

So when ProcessLinesAsync is started – or to be more precise, when it yields the first time (await) – the accept-loop can await for other clients. Quite more scalable. Mature implementations like Kestrel have a more complex accept-loop.

[GSPP]

Adding two related issues:

• https://github.com/dotnet/corefx/issues/5749 Add a clean way to cancel a long-running Socket operation (e.g. accept or connect)
• https://github.com/dotnet/corefx/issues/9698 Add reliable timeouts to socket operations