search

Spreads / SignalW

Even simpler and faster real-time web for ASP.NET Core.
Other
127 stars 13 forks source link

Added Samples, #3

Closed VladimirAkopyan closed 7 years ago

VladimirAkopyan commented 7 years ago

I think your framework is quite good, but needs some guidance & docs. As discussed in #2, I added two samples, for client and server. Deleted ones that were there for SignalR. Both are .Net Core 2. Let me know if I am doing something wrong.

I also added a link to your Nuget Packages & labeled language type in Readme

buybackoff commented 7 years ago

Hi, @VladimirAkopyan! Thank a lot for the contribution! The initial goal was to make it so simple that no special clients are needed, and mental overhead of the server is minimal. An out-of-the-box working minimal example is a great addition.

VladimirAkopyan commented 7 years ago

Cheers! That's exactly why I am here -looking for a library that does not do any bullshit. Only thing is, I think it's important to remove code that has no relevance, otherwise it causes confusion. There was a discussion at websocket-sharp

I only now realised that Spreads is a bigger project that does something. Will have a read in spare time.

buybackoff commented 7 years ago

All Spreads repos published in this org are actually only the top of an iceberg. Unfortunately, I do not have time to properly document and add nice samples even to the main Spreads project.

SignalW is the WAN transport for Spreads. UDP is not an option for Internet, while WS are ubiquitous and give practically the same performance as raw TCP sockets. The difference is of the level of virtual method calls and TPL async machinery, that could be theoretically meaningful for Spreads in the context of high-speed data center (colocation in stock exchange data center, UPD works there), but completely meaningless for WAN.

For IPC I use shared memory - slightly modified Aeron client fork that works standalone without a media driver. Aeron in C# is already the fastest reliable IPC messaging out there, by my fork is even faster (at least one virtual method call less, that is what is visible in profiler).

So my focus is on binary messages in Spreads. Forcing JSON on users gives stupidly slow performance, while Stream to JSON is one method call in JSON.NET. I was hoping that the new SignalR would be released soon and would have direct binary support, but they bloated the library with different transports, pluggable serialization, etc,. while the library is in alpha only since September.

Small binary messages is what SignalW is optimized for. We have inevitable WS overhead I have mentioned above, but everything else is as fast as it probably can be. Spreads's fork of RecyclableMemoryStream is 5x faster than the original, while Spreads's BinarySerializer is literally zero cost for blittable structs. And there are no avoidable allocations all the way down to the final message consumer, since Spreads efficiently pools everything.

So if performance is important, SignalW - powered by Spreads - will win. If something that uses WS is still faster - I will run a profiler and then SignalW will win 😎

[will add this comment to readme later]