Last post Jul 09, 2014 11:33 PM by moity
Mar 21, 2013 03:59 PM|Lt. Cmd. Data|LINK
I know... SignalR requires IIS 8 on Windows 8/Server 2012 to work. I know why.
My costumers won't like to hear "hey, spend a fill thousand dollars on a new Server, install it and configure it just because the new website is cool".
Instead of just asking for support of WebSockets on IIS 7, I'm inclined to add this support myself.
I have plenty of sockets (and websockets) experience, but I need some help in how could I accomplish this on SignalR.
I'm thinking about this:
1) Use a websocket library (such as SuperWebSocket) to listen to a different port than 80 (let's say, 8080). This would allow me to even support IE using Flash, as SuperWebSocket handles that as well.
2) Somehow, inject a connection comming from the browser to SuperWebSocket into the SignalR pipeline (no protocol change here, the client script will remain the same)
I see that SignalR has transport classes, one for IIS 8 WebSockets, one for SSE, one for LongPolling, etc...
So, my question is:
1) How to add a new transport in SignalR (let's call it ExternalWebSocketTransport) and make it valid when negotiating a new connection?
2) It is possible to, once a websocket connection is made through SuperWebSocket, toinject this in SignalR pipeline somehow (creating a ExternalWebSocketHandler, maybe?)
I would love to only extend signalR to support this, instead of changing it's code, I just need a startup guidance to do it so.
I know I can use SSE, etc. for transport when IIS 8 is not available, but we have WebSockets, and they are far less expansive than HTTP...
Mar 21, 2013 11:54 PM|davidfowl|LINK
We used to have really early prototypes of this but we stopped going in this direction beacause it was unclean and IIS8 was coming out anyways. I'm sure you can find a way to hack it in but we don't have any plans to support adding external transports (so
you'll likely face breaking changes in newer versions of SignalR). It's just not worth it (especially since we have transport fallback).
Everybody thinks they need websockets just by default since its the "new thing" but it's better if you focus on your application and then let SignalR do the rest.
My advice, Use SSE and forget about websockets if you don't have IIS8. I'd challenge you to measure the difference between the two before jumping to conclusions. Especially within the context of your application.
It's not realistic to do what you're trying to do in IIS. You'd be better off porting websocket handling code into a custom owin server like firefly (https://github.com/FireflyServer/firefly).
Jul 09, 2014 09:11 PM|moity|LINK
I have a few issues with Signalr that don't seem to come up in discussion all to often, I wonder if you can shed some light.
I have an application where clients are must use to IE10 and above, Chrome or FF latest, hosted on IIS7. For IE the ForeverFrame transport is used while the other 2 support SSE so that is used.
Users of the application typically open a number of tabs, and each tab creates a hub connection to receive notifications. With ForeverFrame this doesn't appear to be an issue but for SSE after 6 tabs are opened you cannot open a 7th (until you close an
existing tab). This is a browser connection limit that I am aware of and not Signalr, however the workarounds for this issue are not trivial or very reliable.
In an attempt to fix this issue I have allowed only 1 tab to connect, and use LocalStorage as a message bus to the others. This works but for various reasons is not very reliable.
Others have suggested using various subdomains as endpoints for the hub (Facebook takes this approach I believe) and then internally redirecting to your main site. The main problem with this is the different domain will not receive the forms authentication
cookie, additionally it complicates deployment.
I have replaced Signalr with a 3rd party WebSocket Server (fleck) and found the implementation to be very simple and clean. The issue I have with this approach is the WS server is hosted on a different port so I need to add an inbound rule to the firewall,
and possibly intermediaries may need the same treatment (basically I'm a bit worried about deployment).
Talking with others about Signalr they didn't seem to be aware of the connection limit issue and when shown weren't all that happy.
IIS 8 is not an option for a lot of corporates yet so it would be great to have something in the meantime.
Jul 09, 2014 10:08 PM|halter73|LINK
Using a 3rd party WebSocket server might not solve your connection limit problem. IE10, for example, has a limit of 6 simultaneous WebSocket connections to a single (sub)domain. This
very issue was filed against SignalR a while back.
Jul 09, 2014 11:33 PM|moity|LINK
Just tried opening 20 tabs in IE, each with an open WebSocket connection with no issue. Tried using window.open() as the issue mentioned too and still no issue.