A socket abstraction solution as part of the .NET eco system

[KieranDevvs]

Currently there is no nice way to create a high performance socket server / client without having to write your own boilerplate for connection handling, error handling, frame encoding and decoding etc. Async sockets are especially a pain to deal with as the API's seem to follow an old async convention.

I know https://github.com/davidfowl/BedrockFramework/ exists, which is now apart of Kestrel, but the whole situation is unclear as documentation is lacking in this area. Is the plan to inject the whole of Kestrel?

I guess my desired end goal is to have something like https://netty.io/ for .NET

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[halter73]

You can take a look https://github.com/redhat-developer/kestrel-linux-transport to see how another custom transport integrates with Kestrel. You're right that we're currently lacking docs in this area.

We're considering transitioning to a shared transport abstraction with HttpClient in .NET 6 (see dotnet/runtime#1793) which would be a new API.

[KieranDevvs]

You can take a look https://github.com/redhat-developer/kestrel-linux-transport to see how another custom transport integrates with Kestrel. You're right that we're currently lacking docs in this area.

We're considering transitioning to a shared transport abstraction with HttpClient in .NET 6 (see dotnet/runtime#1793) which would be a new API.

Im confused... The first line of this issue regarding ProjectBedrock states that the whole purpose of it was to decouple the network stack from kestrel to be used in different types of applications.

Project bedrock is about further decoupling the components of Kestrel so that we can use it as the foundation for our non-http networking stack.

Yet this issue is closed because "the core of Bedrock is within Kestrel":

Closing this because the core of bedrock is in Kestrel. We still have a number of reactions we want to make (#4623 for example) but those should be tracked in separate issues.

What is the intended usage of this abstract network stack?
A) Bedrock is its own library and should be imported by the end user.
B) Kestrel now contains the Bedrock library and thus end users should import the whole of Kestrel to use it.
C) System.Net.Connections API
D) None of the above?

If the answer is B, it seems overkill to import the whole of Kestrel for my intended use.

[davidfowl]

There's layers to this answer. Today Kestrel has a public API that makes it possible to write networking applications (I assume that's why the docs label was added to this question). It's based on the abstractions in Microsoft.AspNetCore.Connections. We'd like to replace the abstractions with the ones defined in dotnet/runtime#1793 and introduce a few implementations (sockets based etc).

The current state of https://github.com/davidfowl/BedrockFramework/ today is that it is built based on those same primitives and exposes a more higher level abstractions for implementing protocols in an efficient way. Bedrock is currently a side project that I don't expect will make its way back into the core platform, but will be built on the same primitives.

Speaking as myself now I do have plans to re-invest in the bedrock project and ship a pre-release to nuget.

[sec]

Hi,
@davidfowl Any update on this one? I've also been looking forward to use Kestrel as non-http server (I want to have something like TcpListener with TLS, but using Kestrel as base). Right now I've started with UseConnectionHandler and ConnectionHandler as initial implementation (with .UseHttps), but maybe there's some better/clever way of doing that?

For ex. how to get client certificate inside OnConnectedAsync?