My app already keeps track of network state (currently I'm only using WiFi)
- if I have no connectivity, I abort the long poll so the wireless radio
interface should not be an issue.
I've alteady tested 'network out of range' issues quite extensively since
my app is being deployed in environments where connectivity comes and goes.
For those tests where I found the safe interval of 4 minutes, the phone was
10cm from the access point. The only thing I cannot completely rule out is
the phone AP roaming (there's a second AP just at the edge of its reception
range) - but it would be a major coincidence. Or the phone does something
in intervals (I heard thei're scanning for wifi networks regularly) that
happens to coincide with the problems. But afaik wifi scanning runs way
more frequent than my connection freezes.
Stephan
Sent from myPhone
On 09.04.2013, at 16:40, "ledz [via Mono for Android]" <
ml-node+s1047100n5713123...@n5.nabble.com> wrote:
mmm it might be useful to dump the radio logs
On 9 April 2013 15:26, Stephan Steiner <[hidden
email]</user/SendEmail.jtp?type=node&node=5713123&i=0>
> wrote:
> I think I may have used the wrong title thus giving the wrong impression of
> what the problem is or isn't.
>
> I already have
>
> System.Net.ServicePointManager.DefaultConnectionLimit = 4;
>
> In my code - I've had this problem earlier (both of you participated in the
> thread last year), and if this were it, the problem would appear
> differently
> (not being able to make any new connections - I can make new connections
> just fine when I get those "timeouts" or rather connection freezes). In
> fact
> I even keep a log of the number of parallel connections just to be on the
> safe side - so whenever I have 2 or more parallel connections, it is noted
> in my log - and I have yet to see 4 parallel connections (I'm not looking
> at
> my code right now but I may have even set the limit higher).
>
> Note that it is not timeouts in making the connection or keeping the
> connection alive - the connection is up and running as far as the TCP layer
> is concerned (confirmed by wireshark traces), the server is processing -
> but
> long poll means the client may have to wait for a long time until something
> is returned to a request). Eventually, my client will abort the connection
> since it thinks it has not received any data, but the server has tried to
> send some.. it is as if the connection has become "frozen" in place. In a
> network trace I see nothing that would show a problem with the connection.
>
> I haven't had time for a simple repro project - but I've found that 4
> minutes is about as long as I can go... if the server responds later, the
> answer may never make it to the client (my client has a dynamic timeout
> duration for the connection controlled by the server - and it is always
> slightly longer than the server side timeout, so the server will after a
> while simply send the current state even if nothing has changed so that we
> don't have any errors in the communication chain). I've experimented for
> hours, and with the server delaying responses by 5 minutes, the response
> then only gets to the client unreliably (one time it works, the next it
> doesn't, etc.), larger values mean the same, and at 4 minutes, things are
> reliable. Also, just because one connection is frozen doesn't mean I can
> initiate another... that works fine and not only that... if I do so, then
> the response from the long poll has a good chance of being delivered after
> all - it is as if making another connection revitalizes the existing
> connection (but this is also not 100% reliable - the additional connection
> may work and should trigger a result being sent to the long poll
> connection,
> but sometime this doesn't work).
>
> Stephan
>
>
>
>
> --
> View this message in context:
> http://mono-for-android.1047100.n5.nabble.com/long-polling-connection-timeouts-tp5713110p5713122.html
> Sent from the Mono for Android mailing list archive at Nabble.com.
> _______________________________________________
> Monodroid mailing list
> [hidden email] </user/SendEmail.jtp?type=node&node=5713123&i=1>
>
> UNSUBSCRIBE INFORMATION:
> http://lists.ximian.com/mailman/listinfo/monodroid
>
--
Gonçalo Oliveira
_______________________________________________
Monodroid mailing list
[hidden email] </user/SendEmail.jtp?type=node&node=5713123&i=2>
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
------------------------------
If you reply to this email, your message will be added to the discussion
below:
http://mono-for-android.1047100.n5.nabble.com/long-polling-connection-timeouts-tp5713110p5713123.html
To unsubscribe from long polling - connection timeouts, click
here<http://mono-for-android.1047100.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5713110&code=c3RlcGhhbi5zdGVpbmVyQGdtYWlsLmNvbXw1NzEzMTEwfC0xNjMyOTU2NzQy>
.
NAML<http://mono-for-android.1047100.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context:
http://mono-for-android.1047100.n5.nabble.com/long-polling-connection-timeouts-tp5713110p5713126.html
Sent from the Mono for Android mailing list archive at Nabble.com.
_______________________________________________
Monodroid mailing list
Monodroid@lists.ximian.com
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
