GPRS networking and Push Messages (AUTD)

[Scott Gifford]

Hello,

I'm working on an app that uses my mobile phone's GPRS network to
implement a simple Push Notification system. My implementation is
based on Microsoft's implementation of always-up-to-date
synchronizatoin (AUTD) for Exchange, which they've written about here:

http://msdn2.microsoft.com/en-us/library/aa446486.aspx
http://msexchangeteam.com/archive/2005/06/07/406035.aspx

Basically, the idea is that the client opens a TCP connection to the
server, then just waits for a response. Periodically, a heartbeat is
sent to make sure the connection is up, or else the connection is
simply torn down and rebuilt.

Exchange's AUTD uses Web services, but for now I'm just using a simple
TCP connection.

I've mostly got this working in a .NET CF 2.0 app in Visual Studio
2008, but I have a few things I'm not sure about.

First, the AUTD articles give the impression that the connection can
be left open for a long time before the heartbeat is required. But on
my device, if I leave the TCP connection idle for 5 minutes or more,
it stops working. That is, any data sent on this connection from
either the client or the server never arrives, and instead the
connection times out or the device sends a TCP reset.
ConnectionManager indicates that the device is Connected. If I
immediately create a new TCP connection, everything works fine. And
the connection stays open if I use a heartbeat less than 5 minutes
(I've tried 4.5 minutes, 4 minutes, and 1 minute). I don't think it's
my firewall, because I regularly leave ssh sessions idle for hours at
a time without losing them. My service is in the U.S. through
T-Mobile.

Is it possible or likely that T-Mobile would enforce a 5-minute
timeout on idle TCP connections? Or is this wildly unlikely and I
should look more closely at my application? Is there something else
that could be causing this? Does anybody have any experience from
Exchange AUTD about how long a reasonable heartbeat time is, and
whether it varies a great deal between carriers? I have read that
Exchange's AUTD calculates an optimal heartbeat time; is any
information available about how they do this?

Second, I'm using OpenNETCF.Net.ConnectionManager to bring the GPRS
connection up before using data. Sometimes when I check the status I
get "Unknown", and when I try to re-connect I get this exception:

Failed to make a connection. ConnMgr returned status Unknown

At least once when I caught the app doing this, the GPRS connection
seemed to be working fine (I could browse the Web with IE). At one
point with my app running overnight, I got this error 763 times!

Has anybody seen this error, and does anybody know what it means? Is
there anything to be done to work around it, or at least get a better
error message?

Third, is it necessary to wake up the GPRS radio when sending data
frome unattended mode, or is it enough to check the status of the
ConnectionManager and Connect() if necessary? For example, to play a
WAV sound from unattended mode I first have to call:

SetPowerRequirement("WAV1:",...);

Do I have to do something similar to wake up the GPRS radio for
sending?

Fourth, it seems there are quite a few quirks working with GPRS, such
as dealing with IP address changes as the device moves, devices going
out-of-range for long periouds of time, possibly proxies or NAT
between the client and server, etc. Does anybody know any good
resources for learning more about what other quirks I'm likely to
encounter in the real world, and how to overcome them?

Thanks for any thoughts or advice!

----Scott.

 

[chris-s]

Hi Scott,

Having done something very similar I can answer a couple of your
questions.

The first one is easy, yes your network provider will timeout your
connection, each provider may vary, we send a keep-alive every 100
seconds which seems to work fine for Orange, O2 and Vodafone.

Secondly, we experienced some oddities and just handled similar things
with a few retries.

Can't answer number three.

Finally, you are quite right in that the device's ip address can/will
change as it moves around, and indeed, the ip address that the device
thinks is usually different to that it which the server sees it as. We
overcame this issue quite easily by writing a 'keep-alive-server', an
application that runs on a server that receives the keep-alive
connections. Each time the device changes it's ip address the next
time it communicates with the server it will be a different connection
than the previous one. We wrote a simple server app that maintains
track of multiple connections with a way to identify a connection to a
specific device and this connection is used to 'push' any data to the
device in question. It was actually a very easy app to write, I'm sure
if you google 'multithreaded tcp server' you can find some working
examples to start from.

Some providers do allow for fixed-ip addressess and other options, but
they don't like doing it, if at all, and the charges can be quite
high.

Hope that helps,

Chris