search

MV10 / mv10.github.io

McGuireV10's personal blog
MIT License
4 stars 2 forks source link

A Minimal Full-Feature Kestrel WebSocket Server - Forty Years of Code #56

Open utterances-bot opened 4 years ago

utterances-bot commented 4 years ago

A Minimal Full-Feature Kestrel WebSocket Server - Forty Years of Code

A Kestrel WebSocket server with realistic features using .NET Core 3.

https://mcguirev10.com/2019/08/18/minimal-full-feature-kestrel-websocket-server.html

alexwieler commented 4 years ago

Thank you very much Jon, all yours articles was very helpful! I'm now using your example to starting develop a live websocketserver. If you need to choose between the kestrel or your .net old websocket server. Is a good option to move to kestrel? I mean kestrel looks pretty promising. But is it suitable for a solution in production?

MV10 commented 4 years ago

@alexwieler Thanks, glad you enjoyed it. Yes, kestrel is definitely production-ready, although I would only use kestrel if I were targeting *nix servers. Performance is better on Windows using IIS and the in-process model.

dzmitry-horbar commented 4 years ago

Thank you! A lot of usefull information inside single topic.

Rehab26 commented 3 years ago

Thank you this helps me alot.. but I am using websocket in asp .net API as websocket server for a chat that is saved in db.. so I developed two connection to two different endpoints one for getting contact list newest updated and second fired when the user clicks on one contact to get all the chat and to send messages to this contact.. is this approach working? or I need to grab it into one websocket connection & how could I do that?

MV10 commented 3 years ago

@Rehab26 It isn't right or wrong, both approaches are common. Web Sockets are relatively "cheap" connections, so it's common to have them dedicated to a specific purpose, as you have done. I tend to go the other route and use a single connection, but that requires developing a custom mini protocol to identify the purpose / content of each message (hiding that extra complexity is part of the reason MS created SignalR).

If your project is destined for production usage, carefully evaluate the number of simultaneous connections your server might have to maintain. In theory a medium-spec server (by today's standards, such as an Azure B-class server) can maintain several tens of thousands of open connections -- but it probably can't use them effectively. My rule of thumb for safe usage is no more than a few thousand persistent connections per server. That leaves a lot of "head room" for processing tasks (e.g. the actual work you want to do via the sockets).

Good luck!