Keeping a data connection alive on Three

It's a long shot, but I wonder if someone from Three network ops side
can comment (off the record if necessary) on the TCP time outs that
their GPRS data connection uses by default?

Our application tries to hold open a socket on a Symbian phone and
then
waits for TCP packets from a server. The sever then pushes events to
the phone on a semi-regular intervals. However sometimes an event will
not be
received inside of 3 minutes and we notice the connection being
terminated from the operator's side.

We've not encountered this problem on Voda, O2, T-Mobile and Orange.
However on Three we are encountering regular TCP time outs forcing
our
application to reconnect every 3 minutes if not data has been sent.

To me a 3 minute TCP time out already seems low. Do we need to be
polling on a more regular basis just to keep the socket open?

As an aside, do the operators gateways honour TCP Keep-alive packets
sent from the server to phone? I've tried sending them every 60
seconds
but we still see our application having to go through a reconnect
cycle.

Any pointers welcomed.

S.

* Simon Tennant wrote:
> It's a long shot, but I wonder if someone from Three network ops side
> can comment (off the record if necessary) on the TCP time outs that
> their GPRS data connection uses by default?
>
> Our application tries to hold open a socket on a Symbian phone and
> then
> waits for TCP packets from a server. The sever then pushes events to
> the phone on a semi-regular intervals. However sometimes an event will
> not be
> received inside of 3 minutes and we notice the connection being
> terminated from the operator's side.
>
> We've not encountered this problem on Voda, O2, T-Mobile and Orange.
> However on Three we are encountering regular TCP time outs forcing
> our
> application to reconnect every 3 minutes if not data has been sent.
>
> To me a 3 minute TCP time out already seems low. Do we need to be
> polling on a more regular basis just to keep the socket open?
>
> As an aside, do the operators gateways honour TCP Keep-alive packets
> sent from the server to phone? I've tried sending them every 60
> seconds
> but we still see our application having to go through a reconnect
> cycle.
>
> Any pointers welcomed.
>
> S.

Aren't you better off just sending a keep-alive ping once every so often
just to keep the connection open? It does seem a bit strange of Three
to do this as it will break most apps that have any period of inactivity
such as the Nokia Maps application.

White Knight <white.knight12908@aol.com> wrote in news:ft09nk$1h5f$2
@custnews.inweb.co.uk:

> * Simon Tennant wrote:
>> It's a long shot, but I wonder if someone from Three network ops side
>> can comment (off the record if necessary) on the TCP time outs that
>> their GPRS data connection uses by default?
>>
>> Our application tries to hold open a socket on a Symbian phone and
>> then
>> waits for TCP packets from a server. The sever then pushes events to
>> the phone on a semi-regular intervals. However sometimes an event will
>> not be
>> received inside of 3 minutes and we notice the connection being
>> terminated from the operator's side.
>>
>> We've not encountered this problem on Voda, O2, T-Mobile and Orange.
>> However on Three we are encountering regular TCP time outs forcing
>> our
>> application to reconnect every 3 minutes if not data has been sent.
>>
>> To me a 3 minute TCP time out already seems low. Do we need to be
>> polling on a more regular basis just to keep the socket open?
>>
>> As an aside, do the operators gateways honour TCP Keep-alive packets
>> sent from the server to phone? I've tried sending them every 60
>> seconds
>> but we still see our application having to go through a reconnect
>> cycle.
>>
>> Any pointers welcomed.
>>


Sure it's not a phone setting? My 3 Nokia has data settings for "always
on" or "when needed". The former holds a data connection open (and kills
the battery), the latter only connects when needed by an application, such
as when Mobile Mail checks for messages.

On Wed, 02 Apr 2008 01:41:18 -0700, Simon Tennant wrote:

> We've not encountered this problem on Voda, O2, T-Mobile and Orange.
> However on Three we are encountering regular TCP time outs forcing our
> application to reconnect every 3 minutes if not data has been sent.
>
> To me a 3 minute TCP time out already seems low. Do we need to be
> polling on a more regular basis just to keep the socket open?

If you're intending your application to be used on 3G, you're going to be
best off writing it to be robust enough to cope with adverse conditions
[packet loss, latency] or downright non-compliance with the usual
internet standards.

--
<http://ale.cx/> (AIM:troffasky) (UnSoEsNpEaTm@ale.cx)
21:57:07 up 41 days, 4:50, 2 users, load average: 0.05, 0.03, 0.04
Convergence, n: The act of using separate DSL circuits for voice and data

* NewsNN wrote:
> Sure it's not a phone setting? My 3 Nokia has data settings for "always
> on" or "when needed". The former holds a data connection open (and kills
> the battery), the latter only connects when needed by an application, such
> as when Mobile Mail checks for messages.

I read what he wrote to imply that when there is a period of data
inactivity 3 kill the connection. It's not a case of Always On since 3
will terminate the data connection if there is a period of no data. So
the OP's suggestion of sending a keep alive PING may in fact be the only
way.

On Apr 5, 10:02 pm, alexd <troffa...@hotmail.com> wrote:
> If you're intending your application to be used on 3G, you're going to be
> best off writing it to be robust enough to cope with adverse conditions
> [packet loss, latency] or downright non-compliance with the usual
> internet standards.

It is a sorry state of affairs when one has to tunnel everything over
the inefficiencies of polling HTTP. But I take your point and we are
adding a fail back for when connection "bounciness" is experienced.

* Simon Tennant wrote:
> On Apr 5, 10:02 pm, alexd <troffa...@hotmail.com> wrote:
>> If you're intending your application to be used on 3G, you're going to be
>> best off writing it to be robust enough to cope with adverse conditions
>> [packet loss, latency] or downright non-compliance with the usual
>> internet standards.
>
> It is a sorry state of affairs when one has to tunnel everything over
> the inefficiencies of polling HTTP. But I take your point and we are
> adding a fail back for when connection "bounciness" is experienced.

The correct fix is to get 3 to fix their systems. You shouldn't be
writing software to get around someone's brain deadness.