.NET Client Connection Limit Issue

[bp74]

I had an issue with the .NET 4.0 SignalR client and the server running IIS7. If i do several calls from the client to the server within a short amount of time, not all calls reach the server. I don't even see the corresponding HTTP-Requests in the IIS log. So i did some tests and here are the results:

The server implements a Hub and a simple method called Echo:

public String Echo(String message) {
    return message;
}

Then the client calls the Echo method on the server:

for (int i = 0; i < 10; i++) {
    hubProxy.Invoke<String>("Echo", i.ToString()).ContinueWith(task => {
        Diagnostics.Debug.WriteLine(task.IsFaulted ? "ERROR" : task.Result);
    });
}

The output in the console shows this (missing results !!!)

0
2
4
6
8

Now i change the app.config on the client.
I change the max concurrent connection limit.

<system.net>
    <connectionManagement>
        <clear/>
        <add address="*" maxconnection="10" />
    </connectionManagement>
</system.net>

Luckily enough the output in the console looks like this (we get 10 results, yeah!)

5
7
2
0
8
4
1
6
3
9

So i think there is an issue on the client. Even if the max concurrent connection limit is 2 the invokes shouldn't be dropped. They should be queued and sent to the server as soon as a connection is available again.

[davidfowl]

Moving to the backlog. We'll take a look at it. Thanks.

[bp74]

Thank you David,

I have two additions facts, maybe they help:

If i don't change the maxconnection settings, but run Fiddler at the same time, it works too. Everything runs slower because of Fiddler and maybe that's the reason why it work.

My Windows 7 computer and the IIS server are in the same building (very low latency) but they are connected to two different networks separated by a Microsoft Forefront TMG firewall.

[davidfowl]

Can you tell me if you can reproduce the problem without fiddler on iis express?

[bp74]

I did the test again with different web servers:

Visual Studio Development Server - works fine
Local IIS Web Server - works fine
Local IIS Express Web Server - works fine

I used Visual Studio 2012 without Fiddler.

[davidfowl]

I mean don't raise the limit then test.

[bp74]

Sorry i wasn't clear, the connection limit was set to default. I removed the setting from app.config.
In other words, the issue can't be reproduced on a local machine.

[davidfowl]

Now I'm really confused. So you're saying that you can't reproduce the problem anymore?

[bp74]

Sorry i'm not a native English speaker, maybe that's the problem...

I can easily reproduce the problem with this setup:
Client runs on my Windows 7 PC.
Server runs on a Windows Server 2008 machine.
Both machines are on different networks in the same building, separated by a Microsoft Forefront TMG firewall.

I can not reproduce the problem with this setup:
Client runs on my Windows 7 PC.
Server runs on my local IIS, local IIS Express or local Visual Studio Development Server.

[stuarthunter]

This issue is still reproducible on the latest beta of the .NET client.

It appears that HttpWebRequest.BeginGetResponse does not queue requests when the outgoing concurrent connection limit (default 2) is reached. If multiple calls are made to this method when no connections are available, the callback for the end method is only fired for the last request. This means that Tasks returned from HttpBasedTransport.Send always remain in a WaitingForActivation state as the continuations are never reached.

This is easily demonstrated with a basic long running server method:

public async Task LongRunningTest()
{
await Task.Delay(5000);
return true;
}

and multiple calls from a client:

hub.Invoke("longRunningTest").ContinueWith(t => Console.WriteLine("Test 1 completed"));
hub.Invoke("longRunningTest").ContinueWith(t => Console.WriteLine("Test 2 completed"));
hub.Invoke("longRunningTest").ContinueWith(t => Console.WriteLine("Test 3 completed"));

With the default of two connections, HttpWebRequest.EndGetResponse will only be called for the first and last invocation.

This was tested using SSE transport.

[davidfowl]

Yes we're very aware of this and are still working through issues with the .NET client. The queueing in system.NET is very counter intuitive but we have proposed solutions for this.

[stuarthunter]

Thanks David. Do you think you'll be able to include a fix in 1.1?

[davidfowl]

Nope.

[davidfowl]

This is no longer an issue. It's been fixed in SignalR 2.0rc

[bp74]

Thanks a lot, this is great news!