We Keep Coding

Does the Signalr server send all pending requests as a single response to poll, while on longpolling?

We are getting pending requests for a signalr client, bunched as an array in a poll response, like below:
{"C":"s-0,9E632",
"M":[
84
{"H":"MyHub","M":"SetSomething","A":[{"myProp1":"setting","myProp2":59.0}]}
1,
84
{"H":"MyHub","M":"SetSomething","A":[{"myProp1":"setting","myProp2":60.0}]}
1,
84
{"H":"MyHub","M":"SetSomething","A":[{"myProp1":"setting","myProp2":61.0}]}
1,
84
{"H":"MyHub","M":"SetSomething","A":[{"myProp1":"setting","myProp2":62.0}]}
1,
6b
{"H":"MyHub","M":"SetMore","A":[{"myProp3":"Somestring","myProp4":0}]}
2
]}
Generally a single response to a poll comes like below:
{"C":"s-0,9E621","M":[
6b
{"H":"MyHub","M":"SetSomething","A":[{"myProp1":"setting","myProp2":59.0}]}
2
]}
I believe the ring buffer stores messages upto the DefaultMessageBufferSize limit, and would be sending those messages to the client when polled for it.
My question is would they be sent one by one, like a queue, one response to one poll or all messages sent together as a response to the first poll (like we are getting, mentioned above)?
Background and actual issue:
We have a signalr client(C1) working on longpolling and our SignalR server in the cloud. There is a user(U1) who connects to the server and sends messages for C1 and we forward those messages to C1 using Clients.User({C1}).{Method} on the server.
When U1 sends multiple quick requests to C1, and C1 is unable to process them quickly enough, we see the bunched response sent to C1. C1 is not configured to handle the bunched response, and it rejects that response and we see a unending loop of the same bunched response to C1 from the server for every further poll.
Would appreciate any insights into this.
Thanks in advance.

Regarding this question's answer, firstly SignalR will never connect by default in long pooling.
Working procedure for SignalR-
It tries to connect with WebSocket.
If it can't connect, then it tries to connect with server-sent events.
Even if it fails, then it tries with server frame.
Even it fails, it uses long polling as a fallback.
More can be found here.
And regarding its performance, you can find more in here.
So, it is tested that SignalR can handle as many requests as a network device can handle, so there is almost no limitation regarding data transfer.
Your question's answer-
In your case, there we need to check few things.
Is HTTPS is enabled? If not, please follow this link to setup HTTPS because, without HTTPS, you will never be able to use WebSocket and it is recommended.
If HTTP is enabled, then it should communicate with WebSocket where this kind of issue will never happen if the network is OK. But for your case, I think, there is some problem with your network so that some data is missing, that's why it is sending too much data at once.
Please check your timeout config for signalR. You can try changing timeout settings for SignalR.
I think, if you follow these 3 things, you could find the solution for your problem.

.NET WebSockets forcibly closed despite keep-alive and activity on the connection

We have written a simple WebSocket client using System.Net.WebSockets. The KeepAliveInterval on the ClientWebSocket is set to 30 seconds.
The connection is opened successfully and traffic flows as expected in both directions, or if the connection is idle, the client sends Pong requests every 30 seconds to the server (visible in Wireshark).
But after 100 seconds the connection is abruptly terminated due to the TCP socket being closed at the client end (watching in Wireshark we see the client send a FIN). The server responds with a 1001 Going Away before closing the socket.
After a lot of digging we have tracked down the cause and found a rather heavy-handed workaround. Despite a lot of Google and Stack Overflow searching we have only seen a couple of other examples of people posting about the problem and nobody with an answer, so I'm posting this to save others the pain and in the hope that someone may be able to suggest a better workaround.
The source of the 100 second timeout is that the WebSocket uses a System.Net.ServicePoint, which has a MaxIdleTime property to allow idle sockets to be closed. On opening the WebSocket if there is an existing ServicePoint for the Uri it will use that, with whatever the MaxIdleTime property was set to on creation. If not, a new ServicePoint instance will be created, with MaxIdleTime set from the current value of the System.Net.ServicePointManager MaxServicePointIdleTime property (which defaults to 100,000 milliseconds).
The issue is that neither WebSocket traffic nor WebSocket keep-alives (Ping/Pong) appear to register as traffic as far as the ServicePoint idle timer is concerned. So exactly 100 seconds after opening the WebSocket it just gets torn down, despite traffic or keep-alives.
Our hunch is that this may be because the WebSocket starts life as an HTTP request which is then upgraded to a websocket. It appears that the idle timer is only looking for HTTP traffic. If that is indeed what is happening that seems like a major bug in the System.Net.WebSockets implementation.
The workaround we are using is to set the MaxIdleTime on the ServicePoint to int.MaxValue. This allows the WebSocket to stay open indefinitely. But the downside is that this value applies to any other connections for that ServicePoint. In our context (which is a Load test using Visual Studio Web and Load testing) we have other (HTTP) connections open for the same ServicePoint, and in fact there is already an active ServicePoint instance by the time that we open our WebSocket. This means that after we update the MaxIdleTime, all HTTP connections for the Load test will have no idle timeout. This doesn't feel quite comfortable, although in practice the web server should be closing idle connections anyway.
We also briefly explore whether we could create a new ServicePoint instance reserved just for our WebSocket connection, but couldn't see a clean way of doing that.
One other little twist which made this harder to track down is that although the System.Net.ServicePointManager MaxServicePointIdleTime property defaults to 100 seconds, Visual Studio is overriding this value and setting it to 120 seconds - which made it harder to search for.

I ran into this issue this week. Your workaround got me pointed in the right direction, but I believe I've narrowed down the root cause.
If a "Content-Length: 0" header is included in the "101 Switching Protocols" response from a WebSocket server, WebSocketClient gets confused and schedules the connection for cleanup in 100 seconds.
Here's the offending code from the .Net Reference Source:
//if the returned contentlength is zero, preemptively invoke calldone on the stream.
//this will wake up any pending reads.
if (m_ContentLength == 0 && m_ConnectStream is ConnectStream) {
((ConnectStream)m_ConnectStream).CallDone();
}
According to RFC 7230 Section 3.3.2, Content-Length is prohibited in 1xx (Informational) messages, but I've found it mistakenly included in some server implementations.
For additional details, including some sample code for diagnosing ServicePoint issues, see this thread: https://github.com/ably/ably-dotnet/issues/107

I set the KeepAliveInterval for the socket to 0 like this:
theSocket.Options.KeepAliveInterval = TimeSpan.Zero;
That eliminated the problem of the websocket shutting down when the timeout was reached. But then again, it also probably turns off the send of ping messages altogether.

I studied this issue these days, compared capture packages in Wireshark(webclient-client of python and WebSocketClient of .Net), and found what happened. In WebSocketClient, "Options.KeepAliveInterval" only send one packet to the server when no message received from server in these period. But some server only judge if there is active message from client. So we have to manually send arbitrary packets (not necessarily ping packets,and WebSocketMessageType has no ping type) to the server at regular intervals,even if the server side continuously sends packets. That's the solution.

Nonpersistent HTTP 1.1 connections faster than persistent one?

I am using Entity framework 4.0 in conjunction with REST web service.
On the client side, during data/entities loading, client is making 40 sequential web requests.
When I set HttpWebRequest.KeepAlive to false (Fiddler shows Connection: Close headers in client-server communication), data loading is faster about 50% (requests are still sequential) - and I am wondering why.
From Wikipedia:
HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using the same TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair.
From MSDN:
When the KeepAlive property is true, the application makes persistent connections to the servers that support them.
When using HTTP/1.1, Keep-Alive is on/true by default.
What´s wrong? How can I speed up persistent requests?

Maybe on the client the limit for no. of concurrent connections per IP is higher for non-persistent connections than for persistent. So when using keep-alive, client may have allowed you to have 10 conns in parallel, but when not using keep-alive, you can have for example 15 parallel connections.
But this will be faster only on local network where establishing connection is really fast. On internet (RTT of 5-200 ms) you would need 3x RTT time (SYN, SYN+ACK, ACK) only to begin new connection. So especially if you have many small requests (for example images under 1kB), the speed of keep-alive can be 4x faster - because you setup the connection only once and then send 1 packet as request and receive 1 packet as response. But without keepalive, you need 3 packets to begin, then send request, then receive response and then 2 packets to close the connection.

How to use CassiniDev.Lib without the timeout?

I am using the CassiniDev.Lib4 DLL and recognized that the server stops responding after a certain amount of time.
Looking at the code in CassiniServer.cs I could see that a timeout of 60 seconds is set:
_server = new Server(port, virtualPath, applicationPath, ipAddress, hostname, 60000);
How can I avoid any timeout of the server? And why is there a timeout?
EDIT: Fiddler tells me:
HTTP/1.1 502 Fiddler - Connection Failed
Content-Type: text/html; charset=UTF-8
Connection: close
Timestamp: 09:18:38.367
The socket connection to localhost failed.
Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte 127.0.0.1:1278
EDIT 2: I'm not sure anymore, that it has to do with an implemented timeout, because I kept time and can't recognize a 60 seconds time window. Sometimes the server didn't respond after 40 seconds after the last click. Or could it be, that a cached website was loaded and the last click didn't trigger a request?
I am really looking forward to your hints!
Best regards,
KB

As a quick walkaround I uncommented the code of DecrementRequestCount() and IncrementRequestCount() in Server.cs. I think there still is a bug in CassiniDev.Lib4.
Cassini now seems to run properly without stopping responding.
I am sorry, that I didn't had more time to dive deeper into this, but I would appreciate any hints or fixes for this.

Unable to make 2 parallel TCP requests to the same TCP Client

Error:
Unable to read data from the transport connection: A blocking operation was interrupted by a call to WSACancelBlockingCall
Situation
There is a TCP Server
My web application connects to this TCP Server
Using the below code:
TcpClientInfo = new TcpClient();
_result = TcpClientInfo.BeginConnect(<serverAddress>,<portNumber>, null, null);
bool success = _result.AsyncWaitHandle.WaitOne(20000, true);
if (!success)
{
TcpClientInfo.Close();
throw new Exception("Connection Timeout: Failed to establish connection.");
}
NetworkStreamInfo = TcpClientInfo.GetStream();
NetworkStreamInfo.ReadTimeout = 20000;
2 Users use the same application from two different location to access information from this server at the SAME TIME
Server takes around 2sec to reply
Both Connect
But One of the user gets above error
"Unable to read data from the transport connection: A blocking operation was interrupted by a call to WSACancelBlockingCall"
when trying to read data from stream
How can I resolve this issue?
Use a better way of connecting to the server
Can't because it's a server issue
if a server issue, how should the server handle request to avoid this problem

This looks Windows-specific to me, which isn't my strong point, but...
You don't show us the server code, only the client code. I can only assume, then, that your server code accepts a socket connection, does its magic, sends something back, and closes the client connection. If this is your case, then that's the problem.
The accept() call is a blocking one that waits for the next client connection attempt and binds to it. There may be a queue of connection attempts created and administered by the OS, but it can still only accept one connection at a time.
If you want to be able to handle multiple simultaneous requests, you have to change your server to call accept(), and when a new connection comes in, launch a worker thread/process to handle the request and go back to the top of the loop where the accept() is. So the main loop hands off the actual work to another thread/process so it can get back to the business of waiting for the next connection attempt.
Real server applications are more complex than this. They launch a bunch of "worker bee" threads/processes in a pool and reuse them for future requests. Web servers do this, for instance.
If my assumptions about your server code are wrong, please enlighten us as to what it looks like.

Just a thought.
If your server takes 2seconds to response, shouldn't the Timeout values be 2000, instead of 20000 (which is 20 seconds)? First argument for AsyncWaitHandle.WaitOne() is in milliseconds.
If you are waiting 20 seconds, may be your server is disconnecting you for being idle?