.NET Core WebSockets – Cross-Platform WebSockets From DMZ to API - Service Zone | Hacker News Reader

.NET Core WebSockets – Cross-Platform WebSockets From DMZ to API - Service Zone

github.com

93 pointsgencebay17 comments

I find the description of the project pretty weird. It uses security related terms (DMZ) that you find mostly in corporate architectures, but doesn't provide any description of what makes this websocket implementation adapted to this use case. It also doesn't provide any kind of benchmark.

It looks like someone from a consulting company created an open source project based on what he's done for a customer.

There are two websocket protocol implementations on .NET side which are ClientWebSocket and WebSocket classes. .NET Core Middleware uses the WebSocket class to handle all incoming websocket protocol connections on server side. This project provides easy manage the connections for all application layer with simple configuration and different message types (Binary or Text).

I preferred this description it because I wanted to associate it with the use case but you can call it a proxy, client or whatever!

Just to clarify since the naming might be a little confusing - NetCoreStack is Gencebay's project. Looks very cool, I'll mention it on our next ASP.NET Community Standup (http://live.asp.net). The ASP.NET team recently released a WebSocket implementation (https://github.com/aspnet/WebSockets) but it's not very full featured yet. For instance, the NetCoreStack project has some proxy handling, whereas I don't think the ASP.NET team's implementation handles proxies yet.

SignalR for .NET Core is under active development (https://github.com/aspnet/signalr), but a release date hasn't been announced. SignalR brings in things like connection and group management, and the update can take advantage of some of the performance and architectural changes in .NET Core.

[Disclaimer: Microsoft employee, Nazgûl]

I'm a C# developer currently developing and maintaining projects using WebAPI, MVC and ASP.Net Core. My main application uses WebSockets as the primary communications channel.

From the README and a quick scan of the code, I have no idea what this project does. It uses unusual terminology in the description, and doesn't seem to even address what problem it's solving.

Presumably those upvoting the post understand and see the value. Can you please help me understand?

I'm somewhat new to websockets but that code looks suspiciously like the "non-scaling" broadcast mechanisms that .NET remoting used to offer. Can I safely assume this mechanism for pushing updates to clients doesn't scale in the same way most use cases (except single-use client requests) in .NET remoting don't scale too?

Could you explain the scaling issues with .NET remoting I knew there were issues but didn't know the specifics.

silver bullet. The idea was a wonderful new world where you could have remoted objects and not have to care about where and how they were. Except, you did have to care. The process of not caring resulted in a world where round-trips were not isolated and an excess of them occurred resulting in awful performance.

I forget the precise table but there were many means of using .NET remoting and basically all the "fun stuff": client-activated server-based objects, sever-based publishing (i.e. like this implementation of websockets), and server-based singletons all had immense problems with scaling. The only means of using .NET remoting that did scale was one-time-use server based services so to scale you'd end up just using .NET remoting like webservices/RPCs or REST APIs and effectively 3/4s of the features were "worthless".

It was an interesting diversion and was eventually "replaced" by WCF. It is still very much used under the covers of a lot of things though. IIRC COM still uses .NET remoting or aspects of it to communicate with .NET apps.

What exactly is the difference between this and the standard .NET Core websockets?

Perhaps its not dependent on OS version like the stock one?

The stock one in .NET Core is a pure managed implementation.

https://github.com/aspnet/WebSockets

What happened to SignalR? That was easy to use and scalable.

Ongoing rewrite for ASP.NET Core:

https://github.com/aspnet/signalr

On mobile so can't inspect the changes but is it really a rewrite?

If really so, that's a bit disappointing because I thought converting to core was going to be trivial.

.NET Core has a lot of things that are still in development unfortunately. Image processing is another major one that I don't think has been solved yet. I really like .NET Core from what I've done with it. Though my like for .NET in general is a bit tainted due to the pure joy of Visual Studio as an IDE.

Just a note that SignalR is being worked on, we announced as much in the .NET Core 1.0 blog post here: https://blogs.msdn.microsoft.com/webdev/2016/06/27/announcin...

(The above says "later in 2016" which was a bit optimistic of us, but its being worked on)

Is there any place where I can see some numbers for how many connections it can handle and at what benchmarks?

Don't suppose there's any chance of getting this working in Unity?

Reply on news.ycombinator.com