I am developing a Windows Phone app that communicates with a server on home LAN over wifi, and I ran into a show stopper: an average round trip time for a tiny HTTP request inside LAN is 600-800ms.
This only happens with a standalone phone. If the phone is connected to PC running Zune the phone starts talking through Zune and the response time drops from 600ms to 20ms (!).
I wrote a small repro program that sends HTTP request every 100ms and ran Wireshark trace.
The trace shows that the server responds right away. It is the phone that delays requests and sends three to five requests at a time as a batch roughly once a second.
More info:
My program is using HttpWebRequest not WebClient.
I tried to spawn threads for each request, no luck.
This happens on WP7 release and on Mango.
The same thing whether I run off my work or home Wifi.
A low level implementation using socket API in Mango exhibits same behavior.
I have seen other posts on App Hub with the same issue. Please help clarify why this is happening.
Perhaps another experiment will help. Put your phone on charge and use the WiFi to send your messages. I suspect this batching is a result of a battery saving feature.
If I understand correctly, cellular networks link layer protocols are bursty so they can virtualise and run more connections than there are transponders. I suspect this is the root of your symptoms.
Related
The OPTION/POST Request is failing inconsistently with a console Error as err_timed_out. We get the issue inconsistently, it's only observed sometimes. Otherwise the request gets proper response from the back end. When it's timing out, the request doesn't even reach the server.
I have done some research on the stuff and found that due to maximum 6 connections to a resource restrictions it may wait for getting a connection released. But, I don't see any other requests pending ,all the other requests were completed.
In the timeline I can always see that it stalled for 20.00 seconds. Most of the time the time is same. But, it only shows that its been stalled for some time nothing else in the timeline.
The status of the request shows failed ERR_Connection_Timed_Out. Please help.
The Network Timing
Console Error
I've seen this issue when I use an authenticated proxy server and usually a refresh of the page fixes it.
Are you using an authenticated proxy server where you are seeing this behavior? Have you tried on a pc with direct access (i.e. without proxy) to the Internet?
I've got the same problem when I choose another ISP. I thought I would have only to put my new ID and password, but it wasn't the case.
I have an ADSL modem with a dry loop.
All others services were fine (DNS resolution, IP telephony, FTP, etc).
I did a lot of tests (disable firewall, try some others navigator, try under Linux, modem default factory, etc) none of those tests were successful.
To resolve the problem ERR_TIMED_OUT, I had to adjust the MTU and MRU values. I put 1458 rather than 1492, which is the default value.
It works for me. Maybe some ISPs use different values. Good luck.
I'm developing a signalr app having a silverlight client and my project structure is
A web app having the server (hub)
a wpf app having the wpf client (for the first client)
a web app for the other web (silverlight) clients
The problem I'm having is that when I try to send a message to other clients in one of the web clients using Firefox or IE, I need to wait around 2 seconds. But if I send another signal or 2 signals in the same time, It works fine. I can assure that my signals are sent on time only if I send 2 messages.
Could this be because of the transport or sthg that I need to configure? Clients are working fine with Chrome.
OK. Forcing the transport to Longpolling has solved my problem.
here is how I start the connection
IClientTransport transport = new LongPollingTransport();
await HubConnection.Start(transport);
You are correct, we have documented the issue on the release notes
Server sent events has known issues on Silverlight
Messages are delayed when using server sent events on silverlight. To force long polling use the following:
connection.Start(new LongPollingTransport());
i see latency issue - when i send a timelineitem from my glassware app, it takes a long time to appear on glass device.
I see the item in developer playground (https://developers.google.com/glass/playground)
Is it isolated issue on my WiFi (unlikely)? or some optimization done at Mirror server which queues timelineitems and sending in a specific interval to glass device?
Thanks
After doing some more investigation (In my case, i have setup private network inside enterprise network), i found out that some of the ports are blocked by firewall settings for incoming traffic from outside network, so glass device was not getting notifications from the Mirror Server.
It is possible either Channel API or XMPP is used in receiving notification messages from Mirror server to Glass. Those ports might have blocked by my firewall settings. I ran wireshark, still it is not clear which protocol or port is used in receiving notifications.
Also it is possible that glass device could get (HTTP GET) newly available cards from the mirror server by polling on specific time interval or other cases(changing WIFI network, etc).
I called Glass help, i could not get any feedback.
I would really appreciate if someone (from Google) could shed some light (port and protocol details) on how Glass gets notification from mirror server when new timeline card is available.
This is a known issue:
https://code.google.com/p/google-glass-api/issues/detail?id=185
Issue has been fixed by updating to XE10.
We have a makeshift SOAP client written in C# connecting to a CXF service on a desktop from a windows mobile device. When this device is connected via ActiveSync, it creates a virtual adapter for the RNDIS connection. This virtual adapter assigns a gateway IP to the host, 169.254.2.2.
When we attempt to go through the connection with the hostname or the host's IP set as the address in the C# client, everything works perfectly. When we however set the IP to be the RNDIS gateway (169.254.2.2), the connection is periodically lost on the server side. The CXF service keeps trying to connect, and eventually succeeds, but this results in a massive slowdown of the connection. There are no errors reported in our logs on the mobile C# side, only on the CXF server.
Does anyone have any clues as to why this is happening? We need to assert that 169.254.2.2 cannot possibly be used as a valid endpoint before we rule it out.
Oh, and in case it helps, the C# client is granted the IP 169.254.2.1 through DHCP after the ActiveSync connection.
The first issue that comes to my head, especially once I saw that you are using DCHP, is that the lease time on the IP from the DHCP server is expiring and the CXF server is having to wait for the DCHP server to issue a new lease.
Try lengthening the DCHP lease if you know that the IP won't be changing and use a static IP if you are able. That will at least remove that point of failure.
I found out the cause of this, but I feel bad for answering because I doubt there was any way someone else could have guessed that this was the problem:
On our CXF server, we have a call to InetAddress.getHostName() which basically does a reverse DNS lookup on the request sent from the C# client.
When using the ActiveSync IP address, there was no entry in the DNS for 169.254.2.1 (of course), so the java class would hang until the method timed out (which took about 20 seconds before it would write a response to the C# client). At 20 seconds per request, this resulted in the massive slowdown and lost connection errors.
We fixed this by moving the call to an executor thread that force-finished after half a second. Because it was in another thread, the slowdown became nonexistent. Glad to have that over with!
I've read that Silverlight 2.0 imposes by design an asynchronous model when communicating with the web server. I haven't had a chance to experiment with Silverlight, but I assume that it uses a thread-pool to manage threads like in the .NET Framework.
Now, since some browsers, most notably Internet Explorer, have an hard-coded limit of maximum two concurrent HTTP connections that can be made on the web server, what happens if I make a bunch of asynchronous requests from Silverlight?
Does Silverlight bypass this limitation in the web browser and open as many HTTP connections as there are threads available, or do the asynchronous requests queue up and wait for one of the two connections to become available?
In IE (haven't tested others) Silverlight is restricted to 2 connections at a time.
The behavior in Silverlight is to simply not make the request. So if you make 5 Async web service requests right in a row, the first 2 will happen, the other three won't. No exception is thrown that i've seen...
Fiddler is a big help here :)
Create a messaging manager interface for your client. Any outgoing request are posted to a queue that this manager processes against. It would serially process queued messages (i.e., when the call back of the last message sent to the server is invoked, can then safely proceed to process the next queued message).
You can consume the other connection resource by keeping a Comet connection open to the server. The server would push any return messages to the client via this Comet connection. You'll need to stamp out-going messages with a unique number that can be embedded as a property on in-coming messages - so that results can be correlated to request. The messaging manager would dispatch a result message to the appropriate handler for that result.
Essentially you end up using two connection resources to establish bi-directional messaging. But there is no artificial limit on the number of requesters on the client (though request will get serially transmitted to the server). The act of sending is always fast, though, because you don't wait for any result to be computed - you just need to deliver the message reliably to the server and return. Results come back asynchronously on the other Comet connection.
We do something along these lines with our Flex client apps in conjunction to Adobe BlazeDS running in our Tomcat web server:
A Flex-based asynchronous stack
Firefox is also limited to two connections, in addition to IE as stated already.
Note that the limit is per hostname.
If you add entries to your hosts file, or use dns aliases you can get more connections. For example in testing, add lines like '127.0.0.1 test1' to your hosts file, and then you can open two connections to http://localhost and two more to http://test1
I guess, being a .NET application Silverlight 2 has an independent from browser limit.
I would assume It is maxconnection attribute in Machine.config as mentioned in http://support.microsoft.com/kb/828219
Firstly the Machine.config file would not be used as the Silverlight control is sandboxed with its own version of the CoreCLR.
I believe that the Silverlight control actually makes use of the underlying browser to make the asynchronous HTTP requests. This is most likely the case considering how the Silverlight control can't gain access to SOAP fault information as the SOAP specification requires that the server returns an HTTP 500 response code and the Silverlight control doesn't get that from the browser hosting the control.
This post here serves to confirm this.
As to the limit of concurrent HTTP connections, I believe IE5 and later limit the number of connections to the same site based on HTTP protocol version - HTTP/1.0 it limits to 4 connections and HTTP/1.1 to 3 connections. Most of the time the web server will limit the number of connections to 2 per client, queueing or discarding the remainder.