For the case of an SignalR client using .Net Framework 4.0 to connect to the server (therefore no WebSockets transport supported) which would be the next fallback transport ?
Moreover, if there is a fallback chain it would be great to know it.
From https://learn.microsoft.com/en-us/aspnet/signalr/overview/getting-started/introduction-to-signalr#transports-and-fallbacks the following are used if WebSockets is unavailable:
Server Sent Events, also known as EventSource (if the browser supports Server Sent Events, which is basically all browsers except Internet Explorer.)
Forever Frame (for Internet Explorer only). Forever Frame creates a hidden IFrame which makes a request to an endpoint on the server that does not complete. The server then continually sends script to the client which is immediately executed, providing a one-way realtime connection from server to client. The connection from client to server uses a separate connection from the server to client connection, and like a standard HTML request, a new connection is created for each piece of data that needs to be sent.
Ajax long polling. Long polling does not create a persistent connection, but instead polls the server with a request that stays open until the server responds, at which point the connection closes, and a new connection is requested immediately. This may introduce some latency while the connection resets.
Update:
The latest docs are available here: http://www.asp.net/signalr/overview/signalr-20/getting-started-with-signalr-20/introduction-to-signalr
Related
I am working on a project where we use signalr to communicate with client. I got the case where client is connected to the server and he is using VPN.
Whenever he lost internet connection he obviously lost connection to hub, but from server side is looking like the connection is still active and OnDisconnectedAsync method is not triggered (half-open websocket?). When he reconnect he is connecting to hub with new connection with different connectionId and old connection is still hanging waiting to be closed.
My question is can i somehow close this connection from server side?
I implemented ping/pong functionality which are sending messages on websocket to client and waiting for response and i want to close this connection if i dont get any message back from client after 30 seconds.
Have you perhaps overwritten some timeout methods?
Take a look at this article from Microsoft: https://learn.microsoft.com/en-us/aspnet/signalr/overview/guide-to-the-api/handling-connection-lifetime-events#timeoutkeepalive
It explains the lifetime of a connection and timeout functionality. Maybe this helps.
Good luck!
I'm trying to route matching domain requests through a single ServerPipe,
but I cant figure out how to get fiddler to reuse that ServerPipe for all ClientPipes
Normal behaviour of a chromium based browser is to open up to 6 connections to a server for a given domain (when there are multiple resources to get). When proxying through fiddler, this normally results in up to 6 ServerPipes. I want to permit the first to establish a server connection, skip connecting the next 5 and then have all client requests use the first server connection. From the browsers point of view it will still have 6 client connections to fiddler.
Here is where I'm at -
Let the first CONNECT request pass as normal, which establishes the first connection to the server
When the next 5 client CONNECT's come in, set the x-ReplyWithTunnel flag on the session in the BeforeRequest handler. This will bypass creating a new server connection, but respond to the client as though a server connection was successfully established
The client sends a bunch of GET requests down the 6 client pipes to fiddler requesting the resources from the server. Those in the first pipe (with the actual server pipe) complete.
Those GET requests in the other 5 tunnels present to fiddler, but no response is processed and sent back to the client.
I've tried all manner of ideas but cannot get fiddler to reuse the single server connection for all 6 client pipes.
All GET requests are to the same domain, so ServerPipe reuse should be ok, no?
Is this even possible ?
If yes, what am I missing ?
Finally worked it out after significant effort.
Under the hood Fiddler uses a "pool" of Pipes to each server.
In my initial post, I was only allowing the creation of a single connection per domain. When the first GET rolled in for a domain, that session takes the only Pipe out of the pool for its use. When the other 5 GET's arrive, they cant find any Pipes in the pool and subsequently fail.
To work around the problem, one needs to throttle the subsequent GET's and only allow them to run one at a time, once each prior GET is complete.
When this orderly process occurs the Pipe will be put back in the pool, and the next GET in the queue will successfully locate a Pipe to use. Unicorns and rainbows then appear.
I used a SemaphoreSlim to "queue" the threads in the BeforeRequest and a .Set() in the BeforeResponse per domain. The basic functionality works for my needs, but a full implementation would require dealing with things like failed Pipes, hanging GET's and flag overrides.
I have a desktop application which connects to a web server via WebSockets. While the connection is open the server can send the client application commands. When the client has executed the command he tells the server that he has completed the task. When this message arrives on the server the WebSocket middleware executes a ReceiveAsync method.
I need to await the response of the client on the server, since I need to do some additional stuff based on the initial command.
Here's and example on how a communication could be done. In this case we are going to tell the client to create a new file.
Client connects to the server via Websocket. The server stores the Websocket with a GUID.
The server sends a "CreateFile" command to the server.
The client receives the command and create a new file.
The client sends a "Created File with name abc.xyz" message back to the server.
The server the registers the file in its internal database to do additional work.
My current state is an asynchronous SendMessage method that I can await. However now I need a way to await the response part.
I already read about a possibility with the TaskCompletionSource and then Task.WhenAll(). I also read about the possibility with a ManualResetEvent.
Currently I'm a bit confused how I should approach this problem.
I am currently developing an IoT that performs HTTP requests to my WCF web server via the GPRS service (GSM Network).
The thing is : I very often (due to the bad GPRS RSSI on my connected object) lose the connection to the GPRS service. The problem is that sometimes, when I perform an HTTP GET on my server, it generates a timeout on the object's side (HTTP code 408), while the server actually received the request : it means that I had connection when I queried the server, but I lost it right after.
However, the server isn't aware of the fact that my object lost the connection, so it will do what it was told to do anyway (delete stuff in the database etc.).
I need very precise synchronization between the object and the server, and I don't want the server to perform database changes if my object loses the connection and doesn't receive the server's response. Which is why I would like to know it this is possible, with WCF, to know if at the end of the API function Call, the server successfully responded to the query or not (have some sort of ACK to be sure that the HTTP communication fully worked on both sides).
Thanks for your help.
I have a tcp server that writes in winforms and a client in android. I connect devices to a wirless network then I disconnect server from this network. However client continue to listen server for a while then it closes its socket. How can I tell client to close socket when server is disconnected from network?
The reason it happens (if I understand the problem correctly) is that there is not inherent way to know that a connection has been closed, unless you try to send a package. So in your client, if you try to send an empty package over the connection, it will immediately report if the connection has been closed.
This is the reason that Heartbeats exist, and you can configure your socket to use them, or you can have your client periodically (or when needed) attempting to send an empty package and report the status of the connection.
There is an excellent article on CodeProject about this, see here.