$.connection.hub.start().done takes 5 seconds to startup in production, works fine in dev.
Server 2012 and IIS 7.5
I remember another user had the same problem
Hub.start - wait for finish
I had the same issue
SignalR tried to connect to WebSocket but fails or your server does not have WebSocket Protocol for IIS installed.
Then it tries to use serverSentEvents and it returned timeout after 5 second
Only then it established longPolling
Thus you can try install WebSocket Protocol or remove serverSentEvents from transport options
Related
I'm trying to get Web Sockets working as the protocol with an ASP.NET 4.8 Framework app that uses SignalR 2.4.2. It works fine with Visual Studio 2019 on localhost, running Windows 10 Pro. It fails on a Windows 2016 server (not Azure) with this error in Chrome 85:
signalr?v=igzza46L1gfiUBzl96WDUmuI9_CUHV_qqd0Kd-fDr8A1:1 WebSocket connection to 'wss://someServer.org/signalr/connect?transport=webSockets&clientProtocol=2.1&connectionToken=...&connectionData=%5B%7B%22name%22%3A%22myhub%22%7D%5D&tid=0' failed: Error during WebSocket handshake: net::ERR_CONNECTION_RESET
and
No transport could be initialized successfully. Try specifying a different transport or none at all for auto initialization.
at Object.error (signalr?vv=...:1)
at g (signalr?vv=...:1)
at v (signalr?vv=...:1)
at h.transportFailed (signalr?vv=...:1)
at signalr?vv=...:1
at WebSocket.e.socket.e.socket.onclose (signalr?vv=...:1)
Opening this URL on the server https://myserver.org/signalr/negotiate to get the SignalR details produces the following:
Url "/signalr"
ConnectionToken "..."
ConnectionId "..."
KeepAliveTimeout 20
DisconnectTimeout 30
ConnectionTimeout 110
TryWebSockets true
ProtocolVersion "1.2"
TransportConnectTimeout 5
LongPollDelay 0
Here's the chain of console responses in Firefox for the failed call:
SignalR: Client subscribed to hub 'myhub'.
SignalR: Negotiating with '/signalr/negotiate?clientProtocol=2.1&connectionToken=...&connectionData=%5B%7B%22name%22%3A%22myhub%22%7D%5D'.
SignalR: webSockets transport starting.
SignalR: Connecting to websocket endpoint 'wss://myServer.org/signalr/connect?transport=webSockets&clientProtocol=2.1&connectionToken=...%3D%3D&connectionData=%5B%7B%22name%22%3A%22myhub%22%7D%5D&tid=8'
Firefox can’t establish a connection to the server at wss://myServer.org/signalr/connect?transport=webSockets&clientProtocol=2.1&connectionToken=...&connectionData=%5B%7B%22name%22%3A%22myhub%22%7D%5D&tid=8.
SignalR: Websocket closed.
SignalR: Closing the Websocket.
SignalR: webSockets transport failed to connect. Attempting to fall back.
SignalR: No fallback transports were selected.
SignalR: Stopping connection.
SignalR: Fired ajax abort async = true.
WebSockets has been installed on the server using these instructions:
https://learn.microsoft.com/en-us/iis/configuration/system.webserver/websocket#windows-server-2012-or-windows-server-2012-r2
https://learn.microsoft.com/en-us/iis/configuration/system.webserver/websocket#how-to-configure-websocket
On the client, it's using the following:
$.connection.hub.logging = true;
$.connection.hub.start({ transport: ['webSockets'] })
.done(function () {
// ...
}).fail(e => {
console.log(e);
});;
In addition, BrowserLink is disabled in Visual Studio, as that's been mentioned as a possible cause of issues.
Additional articles researched:
https://stackoverflow.com/a/37531108/177416
https://github.com/SignalR/SignalR/issues/3148
Some suggested removing the Application_PreSendRequestHeaders from Global.asax.cs but this didn't change anything on the server.
I'm aware that SignalR supports other protocols but I'm trying to get Web Sockets working.
Thanks.
Update: The web sockets protocol also works on the localhost of the server itself, logging in via RDP and using a browser to open the page.
This was a tough nut to crack. Working with the system admins, we discovered it was caused by the load balance/proxy level, which sits in front of all our traffic. By default, it didn't support web sockets. Once web sockets were enabled, SignalR was happy.
I configured a nginx instances as a reverse proxy for a websocket server and established a websocket between client and server, according to the official tutorial https://www.nginx.com/blog/websocket-nginx/.
Then I run nginx -s quit to gracefully shut down nginx.
I found that a worker process is always in a status shutting down.. and I can still send message via the established websocket connection, then the nginx master and worker process will hang up until timeout.
I'd like to know if nginx supports the function that telling both client and server to close the socket connection on transportation level and exit normally, instead of waiting for the websocket time out.
I am using a SignalR Client connection using HubConnection. When calling Start(), an System.Net.WebException is thrown with the following message:
The remote server returned an error: (400) Bad Request.
The server response is:
Not a valid web socket request.
I am running Windows Server 2012 R2 with IIS 8.5
What could be the problem?
The problem was with the configuration of IIS.
You have to install the WebSocket Protocol support in order to connect to SignalR using WebSockets.
We have ASP.NET Web Service running on IIS6 that has long-running methods (processing takes about 5 minutes).
When we call the web service from Win 2003 Server, our client gets HTTP 503 error after waiting for the response for couple of minutes. So we never get the response data back to the client, even though, the call is actually completed on the server (our application logging shows that the whole method gets executed). So the execution on the server side is not stopped, client just stops waiting for the response.
However, when we call the same method with the same parameters and the same client from Win XP workstation, everything works as expected and we don't get any HTTP errors.
Does anyone got any ideas why this error happens only when calling from Server OS?
Is there some registry or other setting where you can control how long OS waits for HTTP responses?
I'm working on Comet support for CppCMS framework via long XMLHttpRequest polls. In many cases, such request is closed by client before any response from server was given -- for example the page is closed, user moves to other page or it is just refeshed.
At the server side I expect that I would recieve the notification that connection is dropped. I tested the application via 3 connectors: FastCGI, SCGI and simple HTTP Proxy.
From 3 major UNIX web servers, Apache2, lighttpd and Nginx, only the last one had closed
connection as expected allowing my application to remove the request from wait queue -- this worked for both FastCGI and HTTP Proxy connectors. (Nginx does not have scgi module by default).
Others, Apache and Lighttpd do not close connection or inform the backend about disconnected
clients, the proceed as if the client is still on line. This happens for all 3 supported APIs: FastCGI, SCGI and HTTP Proxy.
I had opened an issue for Lighttpd, but what
more conserns me is the fact that Apache -- mature and well supported web server as lighttpd
and does not discloses the server backend that client had gone.
Questions:
Is this a bug or this is a feature? Is there any reason not to close the connection between web server and application backend?
Are there real life Comet application working behind these servers via FastCGI/SCGI/HTTP-Proxy backends?
If the above true, how do they deal with this issue? I understand that I can timeout all connections every 10 seconds, but I would like to keep them idle as far as client listens -- because this allows easier scale up -- each connection is very cheep -- the cost is only the opended socket.
Thanks!
(1) Feature. Or, more specifically, fallout from an implementation detail.
A TCP/IP connection does not involve a constant flow of traffic back and forth. Thus, there is no way to know that a client is gone without (a) the client telling you it is closing the connection or (b) a timeout.
(2) I'm not specifically familiar with Comet or CppCMS. But, yes, there are all kinds of CMS servers running behind the mentioned web servers and they all have to deal with this issue (and, yes, it is a pain).
(3) Timeouts are the only way, but you can mitigate the pain, so to speak. Have the client ping the server across the connection every N seconds when there is otherwise no activity. Doesn't have to do anything and you can tack stuff on the reply; notifications of concurrent edits or whatever you need.
You are correct in that it is surprising that mod_fastcgi doesn't support telling the backend that Apache has detected the disconnect or the connection timed out. And you aren't the first to be dismayed.
The second patch on this page should fix that particular issue:
http://osdir.com/ml/web.fastcgi.devel/2006-02/msg00015.html
http://ncannasse.fr/blog/tora_comet
I don't have any concrete information for you, but this article does mention that they can detect when the client has disconnected from Apache. See tora.Queue. And it sounds like the source is available in the neko CVS, so you might be able to find some clues there. Good luck.