WP7: SignalR opens 1 connection per second, using both long polling and server sent events

[Casper-W]

I am using SignalR 5.1, which I got using NuGet. The client is a Windows Phone 7 app, so it is using "SignalR.Client.WP7". The server is hosted on IIS8. My development machine is Windows 8, the production machine is Windows Server 2012, also using IIS8, hosted on an Azure VPC. Both are showing the same behavior.

When I start my app, the SignalR functionality seems to work fine, but when I use Fiddler to inspect the actual data traffic I see some issues:

I continuously see 2 types of requests being made: One with transport=longPolling and one with transport=serverSentEvents
Both request types are fired to the server every 2 seconds. I was assuming that long polling would be able to keep connections open much longer?
SignalR doesn't use Websockets, which is enabled on the server and does work with another library (Websockets4Net). The client does submit the TryWebSockets parameter with true.
I'm especially curious about issue 1 and 2, as I'm worried that this behavior would give a heavy load on the server.

Edit: I have now also tried connecting to the same SignalR server using the JavaScript implementation. This actually does use Websockets. When I disable Websockets the long polling works perfectly, keeping the connection open for a long time.

[davidfowl]

You're using SignalR 0.5.1 (not sure which package version), you should use 0.5.3 if you're not.

1. The request every 2 seconds sound like you have some duplicate requests with the same connection id. It could be the fallback logic messing up and if it is, you can specific a transport specifically.
2. WebSockets isn't supported on the .NET client.

SignalR and Fiddler:https://github.com/SignalR/SignalR/wiki/Using-fiddler-with-signalr

[szved]

Experiencing the same issue as continious requests transport=serverSentEvents then two of transport=longPolling and again each couple of second. Running the WP and AspNet samples from SignalR/samples as client and host respectively.
Basically that renders as "Reconnected", "Connected -> Reconnecting", "Reconnecting -> Connected" event sequence in application interface (maybe the order is wrong though). Same reproduces in any combination as local dev server (IIS Express) or remote (IIS8) one, WP emulator or device.
Any ideas?

[Casper-W]

I have implemented a workaround, by forcing longpolling:

var longp = new SignalR.Client.Transports.LongPollingTransport();
var connectingTask = connection.Start(longp).ContinueWith(task =>

[davidfowl]

We don't support WP7 anymore.

[szved]

@cspare, you've made my day, the workaround does work preventing from reconnects. Was just confused with intercepted requests implying the long polling transport. Now just wondering why this does not work out of box expected in up-to-date samples code.
@davidfowl, thanks for comment.