11

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?

Jon O
  • 6,532
  • 1
  • 46
  • 57
Daniel Revell
  • 8,338
  • 14
  • 57
  • 95
  • 9
    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) – Lars Höppner Feb 05 '14 at 11:33
  • 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. – halter73 Feb 05 '14 at 22:53
  • 1
    @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) – Lars Höppner Feb 05 '14 at 23:15
  • @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? – Daniel Revell Feb 06 '14 at 08:33
  • 3
    IIS doesn't implement WS itself, it depends on the .NET framework implementation in [System.Net.WebSockets](http://msdn.microsoft.com/en-us/library/system.net.websockets(v=vs.110).aspx); 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 – Lars Höppner Feb 06 '14 at 10:58
  • @LarsHöppner The question has been reopened, I think your comments should definitely be the accepted answer to this question. – René Wolferink Feb 11 '14 at 12:17
  • @RenéWolferink thanks for the reminder, I copied my comments into an answer – Lars Höppner Feb 11 '14 at 15:50

1 Answers1

9

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).

Lars Höppner
  • 18,252
  • 2
  • 45
  • 73