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?
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.
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
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.
Related
How can I find out in code client's app (C#), which technology (polling or WebSockets) is used to communicate with the server?
From your hub you can call the following:
Context.QueryString["transport"]
It will return one of the following values: "webSockets", "serverSentEvents", "foreverFrame" or "longPolling".
I would say that your code shouldn't depend on which transport is being used, but it's might be useful in some cases (logging etc).
I've never had to do IPC on Windows before. I'm developing a pair of programs, a standard GUI/CLI app, and a windows service. The app has to tell the service what to do. So, assuming the communication is local only, what would be the best communication method for these two processes?
By best I mean more robust and less error prone, not the best performance nor the easiest to code.
Note I'm asking about what to use, a standard TCP socket, named pipes, or some other means of communication only.
IPC in .Net can be achieved using:
WCF
using named pipes requires .Net 3.0 and above.
Code example
The WCF class NetNamedPipeBinding can be used for interprocess communication on the same machine. The MSDN documentaion for this class includes a code sample covering this scenario http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx
Remoting
The original IPC framework released with .Net 1.0. I believe remoting is no longer being actively developed, and you are encouraged to use WCF instead
Code example
Inter-process communication via Remoting - uses a tcp channel
Resources
GenuineChannels, sell a remoting toolkit that includes a Shared Memory Channel. http://www.genuinechannels.com/Index.aspx
Ingo Rammer, wrote the definitive .Net remoting book, Advanced .NET Remoting, Second Edition
Win32 RPC using csharptest-net RpcLibrary
I came across a project recently that has wrapped the Win32 RPC library and created a .net class library that can be used for local and remote RPC
Project home page: http://csharptest.net/projects/rpclibrary/
MSDN references:
How rpc works: http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx
RPC functions: http://msdn.microsoft.com/en-us/library/aa378623(v=VS.85).aspx
Also has a google protocol buffers rpc client that runs on top of the library: https://code.google.com/p/protobuf-csharp-rpc/
WM_COPYDATA
For completeness it's also possible to use the WIN32 method with the WM_COPYDATA message. I've used this method before in .Net 1.1 to create a single instance application opening multiple files from windows explorer.
Resources
MSDN - WM_COPYDATA
Code example
PInvoke.net declaration
Sockets
Using a custom protocol (harder)
For local only, we have had success using Named Pipes. Avoids the overhead of TCP, and is pretty much (at least for .NET) as efficient as you can get while also having a decent API to work with.
Since you are limited to .Net 2.0 WCF is perhaps not an option. You could use .Net remoting with shared memory as the underlying communication mechanism between app domains on the same machine. Using this approach you can easily put your processes on different machines and replace the shared memory protocol with a network protocol.
The standard method of communicating with a windows service is to use service control codes. Windows services can receive codes from 0 to 255. 0-127 is reserved for system. 128 to 255 can be used for custom commands.
If you need to send complex objects to the service use database, xml, file, tcp, http etc. Other than that for sending control commands like reload configuration, process items etc this control codes should be used.
There are additional functionalities available such as querying the service. See Windows service documentation and api.
http://arcanecode.com/2007/05/30/windows-services-in-c-sending-commands-to-your-windows-service-part-7/
Your best bet is to use WCF. You will be able to create a service host in the windows service and expose a well defined interface that the GUI application can consume. WCF will let you communicate via named pipes if you choose, or you can choose any other communication protocal like TCP, HTTP, etc. Using WCF you get great tool support and lots of available information.
I'd like to add to this discussion. Please rebuke me if this is way out there - but couldn't a semaphore (or multiple semaphores) be used for rudimentary communication?
So,
I found that amazing thing called HTML5 WebSockets, new API. That is still in DRAFT version, but quite well supported. Full-duplex bi-directional communication. I know how to use it via JavaScript, there is APIs. But if I want to use a WebSocket client within my C#/.NET application, how to do that?
For example JavaScript: http://bohuco.net/blog/2010/07/html5-websockets-example/
Are there are any special client libraries for WebSockets in .NET?
sir
SuperWebSocket include a WebSocket server implementation and a WebSocket client implementation.
SuperWebSocket's project page
I've recently done some research into this whilst building a .NET and Silverlight client library for Pusher. I found the following WebSocket client libraries and projects:
Microsoft WebSocket client prototype
SuperWebSocket note: there is a client in there, it's just difficult to find
WebSocket-Sharp
Anaida
For the moment the Microsoft implementation is probably the easiest to use and it also has a Silverlight library. SuperWebSockets has a Silverlight project in the source but not in the latest drop.
Starting from .NET 4.5, WebSocket clients are supported via System.Net.WebSockets.ClientWebSocket
You can browse or download this sample C# app from MSDN Code website: http://code.msdn.microsoft.com/WebSockets-middle-tier-5b2972ce/sourcecode.
To the down-voters of the question, the sample is mainly focused on connecting to WebSocket services, which is another significant use-case for a network-centric C# application.
I haven´t tried the Microsoft implementation, but I think Xsockets has the fastest setup time (nuget package). Under 3 min from start to running a complete socketserver + client (demo chat application). Youtube demo
It has fallback to Silverlight and flash for older browsers.
You could use http://www.nuget.org/packages/Microsoft.AspNet.SignalR/ or http://www.asp.net/signalr
ASP.NET SignalR is a new library for ASP.NET developers that makes developing real-time web functionality easy. SignalR allows bi-directional communication between server and side. Servers can now push content to connected cliently instantly as it becomes available. SignalR supports Web Sockets, and falls back to other compatible techniques for older browsers. SignalR includes APIs for connection management (for instance, connect and disconnect events), grouping connections, and authorization.
A friend an I just released a very lightweight, lean, scalable C# websocket server: https://github.com/Olivine-Labs/Alchemy-Websockets
We built it to use in our online game, so our top concern was the quick and efficient handling of tons of connections. It's, from my research, the most efficient out there. And, as a bonus, it supports flash websockets as a fallback for users without websocket-enabled browsers.
If you're looking for a high performance enterprise WebSocket server, take a look at Kaazing. Kaazing has complete support for .NET including Xamarin.
Here is a step-by-step tutorial for AMQP: Checklist: Build Microsoft .NET AMQP Clients.
[Disclosure: I work for Kaazing.]
Yes, you will need an intermediary server which supports the WebSocket protocol. This server could be written in any language including .NET. Here's one for .NET but it really could be any language. As far as your site is concerned it could be ASP.NET and the client part in javascript which will talk to the WebSocket server.
I'm deploying XSockets.net. The framework works quite good, it is being maintained, the developers offer paid support but for normal issues they are also quite active here in SO and they help a lot.
They offer a .net API for implementing the sockets and also a javascript API for the client.
As a summary, I can recommend it.
You have a few choices
Roll your own - the spec is fairly simple
Use someone else's experimental version, such as this one C# Web socket server
Look into the MS WCF approach
My company is experimenting with writing a proxy server using the .NET Fx 3.5 and C#. From our research I have read that HttpListener is not a good candidate for a proxy server though I am unsure as to why.
We are currently working with the Mentalis proxy example source code though that will involve, among other things, implementing our own logging and performance counters. Using HttpListener will wrap Http.sys which will give us some of the performance statistics we require out of the box.
So why is HttpListener a bad candidate for HTTP proxy work?
(And yes we are considering Squid 3.1 by writing or configuring an ICAP server as well.)
HttpListener is in .NET to provide a major building block for a simple HTTP server. Where simple includes not supporting high operation rates.
Typically HTTP proxies need to be very low overhead to support many concurrent connections as well as providing the proxy's function (which depends on the type of proxy).
Proxies are detailed in RFC 2616 §8.1.3) and that immediately provides one item that (if I understand HttpListener correctly) is not possible:
The proxy server MUST signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects to. Each persistent connection applies to only one transport link.
You might also consider that the windows port of nginx was released a few days ago. Many sites that have squid and varnish experience are very pleased after converting to nginx. Then there is always whatever MS is calling ISA server these days.
Gone off to look at the Mentalis code now :D
I've never had to do IPC on Windows before. I'm developing a pair of programs, a standard GUI/CLI app, and a windows service. The app has to tell the service what to do. So, assuming the communication is local only, what would be the best communication method for these two processes?
By best I mean more robust and less error prone, not the best performance nor the easiest to code.
Note I'm asking about what to use, a standard TCP socket, named pipes, or some other means of communication only.
IPC in .Net can be achieved using:
WCF
using named pipes requires .Net 3.0 and above.
Code example
The WCF class NetNamedPipeBinding can be used for interprocess communication on the same machine. The MSDN documentaion for this class includes a code sample covering this scenario http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx
Remoting
The original IPC framework released with .Net 1.0. I believe remoting is no longer being actively developed, and you are encouraged to use WCF instead
Code example
Inter-process communication via Remoting - uses a tcp channel
Resources
GenuineChannels, sell a remoting toolkit that includes a Shared Memory Channel. http://www.genuinechannels.com/Index.aspx
Ingo Rammer, wrote the definitive .Net remoting book, Advanced .NET Remoting, Second Edition
Win32 RPC using csharptest-net RpcLibrary
I came across a project recently that has wrapped the Win32 RPC library and created a .net class library that can be used for local and remote RPC
Project home page: http://csharptest.net/projects/rpclibrary/
MSDN references:
How rpc works: http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx
RPC functions: http://msdn.microsoft.com/en-us/library/aa378623(v=VS.85).aspx
Also has a google protocol buffers rpc client that runs on top of the library: https://code.google.com/p/protobuf-csharp-rpc/
WM_COPYDATA
For completeness it's also possible to use the WIN32 method with the WM_COPYDATA message. I've used this method before in .Net 1.1 to create a single instance application opening multiple files from windows explorer.
Resources
MSDN - WM_COPYDATA
Code example
PInvoke.net declaration
Sockets
Using a custom protocol (harder)
For local only, we have had success using Named Pipes. Avoids the overhead of TCP, and is pretty much (at least for .NET) as efficient as you can get while also having a decent API to work with.
Since you are limited to .Net 2.0 WCF is perhaps not an option. You could use .Net remoting with shared memory as the underlying communication mechanism between app domains on the same machine. Using this approach you can easily put your processes on different machines and replace the shared memory protocol with a network protocol.
The standard method of communicating with a windows service is to use service control codes. Windows services can receive codes from 0 to 255. 0-127 is reserved for system. 128 to 255 can be used for custom commands.
If you need to send complex objects to the service use database, xml, file, tcp, http etc. Other than that for sending control commands like reload configuration, process items etc this control codes should be used.
There are additional functionalities available such as querying the service. See Windows service documentation and api.
http://arcanecode.com/2007/05/30/windows-services-in-c-sending-commands-to-your-windows-service-part-7/
Your best bet is to use WCF. You will be able to create a service host in the windows service and expose a well defined interface that the GUI application can consume. WCF will let you communicate via named pipes if you choose, or you can choose any other communication protocal like TCP, HTTP, etc. Using WCF you get great tool support and lots of available information.
I'd like to add to this discussion. Please rebuke me if this is way out there - but couldn't a semaphore (or multiple semaphores) be used for rudimentary communication?