System.Net.Websockets

[yallie]

Hello!

Any particular reason why CoreRemoting uses websocket-sharp?
As far as I know, .NET framework has its own websocket implementation
https://learn.microsoft.com/en-us/dotnet/api/system.net.websockets

Why can't we use it to get rid of external dependencies?

Third party websocket implementations like websocket-sharp and fleck
don't seem to be maintained as far as I can see...

Websocket-sharp code base looks like it has some activity, but all commits
seem to be autogenerated by a tool, which is pretty suspicious :)

https://github.com/sta/websocket-sharp/commits/master/

[theRainbird]

Hi!

Any particular reason why CoreRemoting uses websocket-sharp?

System.Net.Websockets is very low level, especially at server side.
So I don't wanted to reinvent the wheel. Same with WatsonTCP.
Implementing a performant and reliable Websocket or TCP server, that runs well on Windows and Linux and also with .NET Framework 4.8 / Mono and .NET 5+, is not an easy task.

Why can't we use it to get rid of external dependencies?

Yes, we can use it. Lesser external dependencies are always better.
As far as I know, there are two options, implementing a server with System.Net.Websockets:

• Using HttpListener
• Using the ASP.NET (Core) stack

HttpListener would be the more lightweight way with a lot of handwork to do.
The ASP.NET (Core) stack itself is a big dependency, but is a ready to use and would be easier to get in a reliable state.
But there are many differences in ASP.NET with .NET Framework 4.8 and ASP.NET Core.
This could be also be a lot of work.

Websocket-sharp code base looks like it has some activity, but all commits
seem to be autogenerated by a tool, which is pretty suspicious :)

Looks creepy.

[yallie]

System.Net.Websockets is very low level, especially at server side.
So I don't wanted to reinvent the wheel. Same with WatsonTCP.

Oh, I see... I was unaware that HttpListener support for websockets is so incomplete.
Now it makes sense why is there so many third party websocket implementations for .NET.

[yallie]

Implemented in commit d394eb3.

[yallie]

...or, rather, commit e564f59.

[sancheolz]

@yallie I checked the speed of CoreRemoting on the current revision 4d332a7 on windows 10 x64 with my benchmark.

net4 Remoting     tcp    0:14:22
net6 CoreRemoting tcp    0:24:15
net8 CoreRemoting tcp    0:14:46 
net8 CoreRemoting ws     0:11:11 

CoreRemoting with a web socket on net8 is faster than implementation of Remoting on .net framework 4.7.2.

[yallie]

Cool!
That's great, thanks for the info :)

Could you please add your benchmark project to the repository?
Please! :)

[yallie]

Would be great to be able to run optional benchmarks on Github actions.
Triggering with a commit message, like «Refactored session repository, run benchmark» 📊

[sancheolz]

The benchmark is very much related to closed-source code, but it may be possible to distinguish such typical operations as sending DataTable, string, byte[], int and receiving them. There are also parallel RPCs.

It is really interesting to compare the speed of work with different serializers and channels (for example, quick).

[yallie]

Yes, that would be very interesting!

If you find the time to prepare a PR with a stripped-down version of your benchmark without any closed-source code, I would really appreciate it. We'll use it as a starting point, add different channels and serializers, etc. QUIC looks promising for .NET 9+ framework. Perhaps someday I'll add a zeromq-based channel as an alternative to WatsonTcp, I'm really curious if it performs better.

[sancheolz]

Can we use BenchmarkDotNet for performance checks?