Is Visual Studio's Browser Link feature able to use web sockets?

Question

I understand that SignalR is used to communicate with client browsers using the injected artery script. I have what seems to be a common problem, which is that my browser's network log is filled with entries that look like this:

.../arterySignalR/poll?transport=longPolling&connectionToken=...

This tells me that SignalR has fallen back to long polling instead of using web sockets. Assuming that we have a browser that supports web sockets, and that browser is running on the localhost, shouldn't SignalR default to using web sockets? What might cause it to fall back to long polling?

Delly

this question should not have been closed as "primarily opinion-based"; the question was not whether WebSockets would be a better option, but why the connection might not be using WebSockets even though the browser and SignalR support it; this can be answered entirely based on facts (even though it might require more information) – Tamatave

Lars is right. In my experience, Browser Link does use WebSockets. I would like to get more information to help determine why this is happening. – Oculomotor

@Dan are you running VS on Windows 7? WebSockets support in .NET isn't implemented for Windows 7. (not sure if / when the question will get reopened, so I'm putting this here now) – Tamatave

@LarsHöppner Thanks for your response. We do all happen to be running Windows 7, but do you have any idea how .NET does not support it? The browser supports it, and I think that the hidden browser link iisexpress(8?) process does too and SignalR definitely does. SignalR supports windows 7 too. How else might .NET come into play? – Delly

IIS doesn't implement WS itself, it depends on the .NET framework implementation in System.Net.WebSockets; as you can read in the link to MSDN, you simply don't get an actual implementation of the necessary classes when you install .NET 4.5 on Windows 7; so SignalR has to go if (windows7) { abandonShip(); } and then use one of the fallback options – Tamatave

@LarsHöppner The question has been reopened, I think your comments should definitely be the accepted answer to this question. – Goldiegoldilocks

@RenéWolferink thanks for the reminder, I copied my comments into an answer – Tamatave

Answer 1

Short answer

Browser Link will only use WebSockets on Windows 8 or Windows Server 2012

Longer answer

The following would explain the issue if you're using Visual Studio on Windows 7, Windows Vista or Windows Server 2008:

IIS (Express) depends on the .NET framework implementation in System.Net.WebSockets to handle WebSocket connections; as you can read in the link to MSDN, you simply don't get an actual implementation of the necessary classes when you install .NET 4.5 on Windows 7.

So in that case, the server can't agree to the client's request to change from standard HTTP to the WebSocket protocol, which forces the SignalR client to use one of the fallback options (in your case: long-polling).

Alexandretta