12

I'm looking for an open source, cross-platform, actively maintained .NET library which provides websocket functionality for both clients and servers, in such a way that most of the code (after connection is established) can use the same abstraction regardless of which side of the connection it is on. Ideally, it would be a platform-independent implementation of System.Net.WebSockets, but I don't really care if it defines its own types, so long as there's some single abstract WebSocket class that can be shared by client and server code.

Things that I've looked at and that did not qualify (but correct me if I'm wrong):

  • System.Net.WebSockets (client only, Win8+ only)
  • WebSocket4Net (client only)
  • WebSocket Portable (client only)
  • Fleck (server only)
  • WebSocketListener (server only)
  • SuperWebSocket (server only)
  • Owin.WebSocket (server only)
  • PowerWebSockets (proprietary)
  • XSockets (proprietary)
  • Alchemy Websockets (last release in 2012, many active bugs in the tracker with no answers)

The only one that I could find that seems to be matching the requirements is websocket-sharp. However, what worries me there is the sheer number of opened issues in the tracker along the lines of clients unable to connect, invalid data frames etc - it sounds like it's not very mature yet.

Are there any other candidates that match my requirements that I have missed? Or am I wrong about any of the libraries listed above being client/server only?

Improve this question
13
  • Why do you need client and server at the same time from the same vendor? WebSocket is a standard, if you take for example WebSocketListener and WebSocket4Net it should work. And if you are in control of both server and client... why WebSocket and not directly TCP? Commented Nov 2, 2015 at 23:04
  • I don't really want to go into too much detail here (and it's largely irrelevant in any case). Basically, there are two components that need to communicate with each other, and either one of them can be the client and the server, depending on the exact scenario. Once the connection is established in either direction, the rest of the code doesn't really care which one is the client and which one is the server. Consequently, I would like a single abstraction for websocket that I can use everywhere, such that the only code path that is different is the one that establishes connection. Commented Nov 2, 2015 at 23:25
  • Why not TCP - websockets have some desirable properties that HTTP provides for free, such as the ability to proxy connections, and generally better interaction with firewalls etc. Commented Nov 2, 2015 at 23:26
  • To clarify, the client and the server libraries don't need to be from the same vendor, so long as they share the same abstraction. E.g. if there are two separate libraries, one of which implements websocket client, and the other implements websocket server, but both do so by implementing System.Net.WebSockets.WebSocket, then that'll work for me. Commented Nov 2, 2015 at 23:28
  • Well in my experience a WebSocket is just a transport and your software should never be aware of such detail. Usually I have an abstraction of my own or the communication goes through a service bus, with a listener that writes messages to and reads messages from the queues. Commented Nov 2, 2015 at 23:38

3 Answers 3

Reset to default
10

Look at Microsoft's SignalR. SignalR is a higher level abstraction around websockets. SignalR also allows the client to be written in .NET (C#). From the SignalR documentation:

The SignalR Hubs API enables you to make remote procedure calls (RPCs) from a server to connected clients and from clients to the server. In server code, you define methods that can be called by clients, and you call methods that run on the client. In client code, you define methods that can be called from the server, and you call methods that run on the server. SignalR takes care of all of the client-to-server plumbing for you.

SignalR also offers a lower-level API called Persistent Connections. For an introduction to SignalR, Hubs, and Persistent Connections, or for a tutorial that shows how to build a complete SignalR application, see SignalR - Getting Started.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

Correct me if I'm wrong, but SignalR is managed only - meaning that both sides of the connection would have to be managed (and to use SignalR). As one side is a native application, it's not an option here.
Your question specifies that you're looking for a .NET library. SignalR's server-side is .NET. There are a number of different client-side options: .NET, Javascript. There's even a Python client. What are you using on the client side? What are you using on the server side?
My question specifies that I'm looking for a managed client and server library for websockets specifically, not just for any kind of IPC. The protocol is part of the constraints. It does not really touch on the other side of communication, but it is a native (C++) application. I'm willing to explore other possibilities for a protocol, but it has to be open, documented, reasonably widespread, and have libraries available for both .NET and C++.
Alternatively, if there's a way to directly use SignalR websocket implementation somehow, that would also be interesting.
That still uses SignalR protocol on top of the transport, so far as I can see, so the other side (which, to remind, is in C++) has to know how to speak it - i.e. it needs a native SignalR implementation. I've looked around and SignalR client libraries for C++ exist, but I couldn't find a server implementation for it (or, for that matter, for other languages). To remind, both components in my scenario need to be able to act in either the client role or in the server role at the point connection is established.
|
1
+200

One another solution is to make use of Edge.js. This is a .NET library that utilizes Node.js. You could let Node.js to act as both the server and client of the WebSocket channel. And then utilize Edge.js to act as the bridge between the worlds, Nodejs and the .Net. Have a look at the following, there are plenty of samples as well. github.com/tjanczuk/edge/tree/master#scripting-clr-from-nodejs. Both are excellent frameworks that are actively maintained.

However the use of Edge.js does introduce an additional dependency, node.js

Improve this answer

Comments

0

You can take a look at the WebSocketRPC. The library is based on the System.Net.WebSockets and it is portable. Moreover, it auto-generates JavaScript client code and has support for ASP.NET Core. I suggest you try-out samples first located inside the GitHub repository.

Disclaimer: I am the author of the library.

Improve this answer

1 Comment

Link does not work

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.