API's for creating custom WebSocket server's without dealing with transport code. Bedrock?

[vadrsa]

Is there an existing issue for this?

• [X] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Sometimes using SignalR is not an option, like when the client is an IoT device with a custom WebSocket protocol. In those cases currently(as far as I have researched) the fallback is to very low level WebSocket API's. As a solution for me, I created a SignalR "fork", removed the SingalR specific code and added a protocol-agnostic application layer on top(https://github.com/vadrsa/SimpleR). But I just discovered that there is a community effort(Bedrock) to solve this problem I had and many other related problems in a more generic way. I am very excited to see such a proposal coming to life although at a slow pace. I would be more then happy to contribute and help bring the proposal one step closer to the end goal. I would appreciate if someone can point me in a good direction on how to find/contribute to discussions/implementations of this parts of aspnet core.

Describe the solution you'd like

I guess the general overview is given by @davidfowl here https://github.com/dotnet/aspnetcore/issues/4772.

Additional context

No response

[Tratcher]

Bedrock works at a layer lower than HTTP and WebSockets, focusing mainly on the transport (TCP, TLS), I don't know how applicable that is here. @davidfowl

[BrennanConroy]

Would the MapConnectionHandler API be what you want? It keeps the SignalR concept of different transports but gives you the lower layer (but higher than websocket APIs) of reading directly from the System.IO.Pipelines pipe.

Example of it in use: https://github.com/dotnet/aspnetcore/blob/2e94b96499b54342bd0edf7c849772d8a5513da6/src/SignalR/samples/SocialWeather/Startup.cs#L35 https://github.com/dotnet/aspnetcore/blob/2e94b96499b54342bd0edf7c849772d8a5513da6/src/SignalR/samples/SocialWeather/SocialWeatherConnectionHandler.cs#L35-L38

[BrennanConroy]

Also, if this is specifically about using WebSockets but not wanting to use the low-level WebSocket APIs then there is an issue tracking making a higher layer WebSocket API. https://github.com/dotnet/runtime/issues/77060 is that more what you're looking for?

[vadrsa]

Would the MapConnectionHandler API be what you want? It keeps the SignalR concept of different transports but gives you the lower layer (but higher than websocket APIs) of reading directly from the System.IO.Pipelines pipe.

Example of it in use:

https://github.com/dotnet/aspnetcore/blob/2e94b96499b54342bd0edf7c849772d8a5513da6/src/SignalR/samples/SocialWeather/Startup.cs#L35

https://github.com/dotnet/aspnetcore/blob/2e94b96499b54342bd0edf7c849772d8a5513da6/src/SignalR/samples/SocialWeather/SocialWeatherConnectionHandler.cs#L35-L38

I use this approach in https://github.com/vadrsa/SimpleR, but that still requires to copy and modify a lot of code from SignalR to my repo. Two main things are https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/common/Http.Connections/src/Internal/HttpConnectionDispatcher.cs and https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/common/Http.Connections/src/Internal/Transports/WebSocketsServerTransport.cs. WebSocketServerTransport can be copied without any modifications, but the dispatcher needs to be stripped from SignalR specific code.

[adityamandaleeka]

@vadrsa Would https://github.com/dotnet/runtime/issues/77060 address your needs?

[davidfowl]

I think that's the right issue to track for this one.

[adityamandaleeka]

OK, closing this one since we have the other one.