With the new .Net Core implementation, this 'could be rather trivial'

@James I don't know what your comment is in response to or what it has to do with AngularJS, but if your talking about common protocols, Server Events (which is just HTTP) is a much better more natural fit than WebSockets.

And how does that help me build C# back ends for AngularJS front ends? Or, for that mattet, how does it help me build my services for common protocols built into the browser, such as ws:// and https:// ? Answer is you don't.

@Kunjan, SignalR and websocket support are different things. SignalR is primarily built for small message, distributed comms while websocket is a full-duplex tcp-based protocol without any such restrictions.

2 issues I've run into myself when trying to use signalr to do some out of the ordinary use case stuff.
https://github.com/SignalR/SignalR/issues/1114
https://github.com/SignalR/SignalR/issues/1205

Doing the same (sending an image) over websocket (XSockets implementation) was trivial and had no such issues.

If ServiceStack had websocket support that'd be pretty awesome, it would allow for the creation of duplex comms in a somewhat standardised manner.

Is SignalR a perfect project that can solve every problem? Can we ignore the root, don't have any understanding of websocket, never implement anything with websocket alone but all built on top of SignalR?

There are also other alternative out there. XSockets, WebSocket listener.

If you use either XSockets or SIgnalR, which means you are dependent on their communication rule, if they ever change without backward support, which you will suffer. That's what exactly happen from SignalR 1.0.0RC1 to 1.0.0 RC2. Protocol version upgrade without backward support. That means if your server change, all client have to upgrade.

There is another uservoice for joining Servicestack with SignalR. If that happens then it will be not needed.
Note: In normal case servicestack + singalR are working without any issue.