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?
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).
Related
I am aware of communication between a C# server and C# client using SignalR. Along with C# client, I have C++ client apps where I need to communicate with the same C# server that is used to communicate with C# clients.
For communication between C# server(console application) and C# clients(Desktop) i followed the approach in SignalR Desktop approach
In the above link it is very clear how do we establish a connection to hub and communicate with the server. Similarly I want to have MFC application as client and I want send some messages to the MFC client from C# server. I don't have any idea like how do i establish a connection from MFC app. I don't know whether it is possible or not.
Could anyone please help with a sample on how C++ signalR client connects to a C# client.
Actually, a SignalR C++ client already exists. If you are on Windows you can use NuGet to get the package. There are different packages depending on the toolset used to build the code (important because of the runtime the client is linked against) - v120 uses toolset shipped in VS2013, v140 uses toolset from VS2015. For instance https://www.nuget.org/packages/Microsoft.AspNet.SignalR.Client.Cpp.v140.WinDesktop/1.0.0-beta2 is a package for desktop apps built with VS2015.
I wrote a post on how to use the client as well as a miniseries on using cpprestsdk (a.k.a. Casablanca) - a library which provides async functionality in C++. You need to know this stuff to be able to consume the client since it returns tasks (think promises).
The code also compiles on Linux (and I heard it can be compiled on MacOS but I personally haven't done it).
I installed the SignalR package when our project was running .net 4.0. We since upgraded to 4.5 and I want to support WebSockets. I uninstalled Signal packages and reinstalled SignalR (per this answer). However the SignalR DLL versions (1.1.0/1.1.3) are identical in both cases.
Here is my configuration:
ASP.NET 4.5
IIS 8.0 (Windows Server 2012)
WebSockets feature enabled on the server
A WebSocket supporting browser (latest version of Firefox)
Even though I have all these required things, I still get this:
{"Url":"/signalr","ConnectionToken":"Yy6qHcSMMm4vPl9i3ungxJ5aa2P0SJh4UoU4pelAyFcMud0596UaeB6x8AmhZ2SxW_MPk23QXrKGkwar7LjLLnWlBZx1nokd6LRe96k8D-Oua3kSnKsyDa1RrPTE0n9FyaUO9rK3caLfue20Dmx5UkB9F2TKusPD4PDqQw2","ConnectionId":"b7b00e98-3128-4fbb-ba63-fb16f922f168","KeepAliveTimeout":20.0,"DisconnectTimeout":30.0,"TryWebSockets":false,"WebSocketServerUrl":null,"ProtocolVersion":"1.2"}
I guess the important parts are:
"TryWebSockets":false,"WebSocketServerUrl":null,"ProtocolVersion":"1.2"
Does this mean that I am not using WebSockets? What could I be missing?
Thanks so much.
WebSockets are supported in all major versions of SignalR.
Therefore the question is "what is required for my SignalR application to use WebSockets?"
ASP.NET 4.5
IIS 8.0 (Windows Server 2012 or Windows 8)
WebSockets feature enabled on the server
A WebSocket supporting browser
Now that we've established what is required to have a WebSocket enabled application it seems that your missing the enabling of the WebSockets feature.
To enable WebSockets on your server follow the "Step by Step instructions" here.
Hope this helps!
I know your problem - the same that hit ours!
Your problem is the client you are running from.
The client Windows stack must be > Windows7 to use WebSockets on a
.Net Client
This caught us too!
Browsers aren't affected as they have their own WebSocket stack, but the Windows .Net networking stack doesn't have WebSockets.
Windows 8/Windows 2012 and IIS 8 fixes that.
This is why the SignalR load tester (crank) can't use WebSockets when run on Windows7, only in Windows 2012 (regardless of server)
We since upgraded to 4.5 and I want to support WebSockets.
I'm running Windows 2012 Server, IIS 8, WebSockets feature installed on server and I still get this
Since you are using ASP.NET 4.5, IIS 8 and Windows Server 2012, the problem should be relying on how you migrated the project to .NET framework 4.5 or with the browser. Given that most of the modern web browsers support web sockets, I highly doubt your references are still for the .NET framework 4.0.
Try by creating a new project using .NET framework as 4.5. Simply setting the target using project properties sometimes doesn't update the assemblies.
I have a bit of an issue.
I am using the self-hosting example (http://www.asp.net/signalr/overview/getting-started/tutorial-signalr-self-host) and I have installed the 2.0 (beta2) packages from nuget.
I have my hub running on a webserver and my js client on my localhost.
Webserver is windows server 2012 with websockets enabled in roles.
My solution is set to target .NET 4.5 BUT has started out as 4.0. I have installed the nuget packages AFTER changing the solution target.
Client is running IE9 on Win7.
Now, when I check my referenced .dll's in Visual Studio their Runtime version is listed as 4.0. I am unsure if this means anything.
My problem is, I cannot connect my JS client to the hub, IF I tell it to use websockets.
If I don't specify websockets as transport, it connects fine, through longpolling.
What do I do? I have no idea what to try next.
IE9 does not support web sockets.
On my IIS 7.5, my SignalR application always used long polling.
As per my search, IIS 7.5 does not support WebSockets yet.
I hope, I missed some tools or configurations to enable WebSockets in IIS 7.5. Or I didn't?
You cannot use WebSocket on IIS 7.5 (in other words on Windows Server 2008 R2 or Windows 7) because it requires HTTP.sys level changes AFAIK. So, you need IIS 8.0 and Windows Server 2012 or Windows 8 combination to leverage WebSocket. Also, IIS Express 8.0 supports WebSockect, too but you cannot still leverage that if you are on an OS which is lower than Windows 8 or Windows Server 2012.
IIS 8 Express Supports websockets New Features
Windows 7 is considered a Down-Level Operating system and doesn't support Web Sockets. Known Issues and Limitations
Time to upgrade to Windows 8 if you want to support for web-sockets!
Here's a summary of the required setup steps to host on Windows 2008r2 with IIS 7.5:
Update the SignalR application's web.config file to enable "run all managed modules for all requests" (for short, this is the RAMMFAR setting).
Update the web page that uses SignalR to communicate with the server:
Add a reference to the json2.js library.
Add a tag that forces the content to display in a recent browser mode.
Set up a Windows Server 2008r2 with IIS 7.5 as follows:
Install the .NET Framework version that your SignalR application requires.
Create a site and associate it with the appropriate application pool.
Update the Signalr Application's Web.config File
In your SignalR application's web.config file, add the RAMMFAR setting to enable running all managed modules for all requests. This setting was required to get the SignalR sample application running in on Windows 2008r2 and IIS 7.5 in all browsers.
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
</modules>
</system.webServer>
Update the Web Page that Uses SignalR
In the application web page that uses SignalR to communicate with the server, add the following code.
Add a reference to the json2.js JSON parser library. This script provides a JSON parser for previous browser versions that don't have it. You can add the script in one of two ways:
Add the NuGet package json2.js to your project, and then reference it in your web page:
Or as an alternative, reference json2.js on a CDN:
Add the following tag in the head section of the page. This tag, specifically the IE=edge value, forces Internet Explorer to display content in the most recent version available, rather than earlier modes (such as IE7) which prevent SignalR code from working.
Set up Windows Server 2008r2 and IIS 7.5
As noted, I built the sample SignalR application from the Getting Started with SignalR tutorial on .NET 4. This is a common hosting scenario on Windows 2008r2 and IIS 7.5. The server was a new default default installation of Windows Server 2008r2 and IIS 7.5.
Install the required .NET Framework version. In this case I installed .NET Framework 4.
Create a new site in IIS Manager, and associate the site with an application pool. Use integrated mode application pools, classic mode is not supported for SignalR. For this application I used the ASP.NET v4.0 application pool.
After following the above setup steps, I was able to deploy the .NET Framework 4-based version of the Getting Started with SignalR sample to the server, and it worked perfectly in IE (versions 8, 9, and 10), Chrome, and Firefox even though it was using fallback transport methods (forever frames in IE, and server-sent events in the other browsers). The interesting thing for SignalR developers is that apart from the above steps, I didn't have to change a single line of the SignalR code anywhere in the application to make this work.
This is a simple case but shows that SignalR really does support "automatic fallback" to earlier transport mechanisms when websockets support is not available on the server.
Where can I download websocket server for Windows. Easy to install. Different from node.js I have already tried this one and couldn't manage to run it on my computer.
If you are developing for Windows you'll probably be using .NET. Here are a few .NET WebSocket server options (I'll also be updating this realtime technologies guide with tech as I find them).
XSockets
SuperWebSocket
WebSync (which works with IIS)
Pokein