Hacker News Reader

Comment by skyde | Hacker News Reader

Could someone explain why "ASP.NET Core 1.1" Kestrel webserver decided to use LibUV DllImpor [1] instead of .NET Asynchronous Server Socket (System.Net.Sockets) [2]. Does that mean that the managed implementation of Async socket is broken and was too slow? [1] "https://github.com/aspnet/KestrelHttpServer/blob/dev/src/Mic.... [2] https://msdn.microsoft.com/en-us/library/bew39x2a(v=vs.110).....

View on HN

It means that development on Kestrel started before work on making System.Net.Sockets cross-platform was completed. The programming model for libuv and .NET Sockets is different enough (mostly in terms of threading) to make the transition non-trivial.

Some recent basic testing show .NET Sockets perform at least as well as libuv. We are strongly considering transitioning Kestrel to Sockets at the same time we migrate from Streams to Pipelines. [1] Pipelines are basically push based Streams that require less total allocations to use. This is because Pipelines allow better memory sharing between producers and consumers.

[1] https://github.com/dotnet/corefxlab/tree/master/src/System.I...

Disclosure: In case it wasn't already obvious, I work for Microsoft on Kestrel.

Are there any plans for RIO?

In the long term yes. When we switch to System.Net.Sockets it will be done with an emphasis on transport agnosticism. [1]

ATM, it looks like Sockets will be the priority since it's a cross platform API more similar to what libuv currently provides.

[1] https://github.com/aspnet/KestrelHttpServer/issues/828

Oh thank <insert deity> you distinguish readers and writers by their own interfaces. The kitchen-sink functionality available in System.IO.Stream has always been a nuisance to me.

Reply on news.ycombinator.com