GPRS comms problem - network provider issue?

[chris-s]

Hi folks,

I've spent quite some time implementing a GPRS comms module for our
application to send data back to a SQL Server db over GPRS.

Basically, it establishes a GPRS connection and then uses RDA to send
back the data using 'insert' statements in small blocks. It also uses a
few webservice calls to validate the device id. This is the technique
we have always used for non-gprs comms and works 100's of existing
devices over several years without a hitch. For testing purposes we
have a server in the office setup with a real-world ip address running
IIS only for this, the SQL server is on another server in the office.

However, under GPRS I am getting some odd behaviour that seems to point
to the connection provided by the network provider, sometimes it works
for a couple of hours and then it will just start failing for hours on
end, typically I get the message...

'A request to send data to the computer running IIS has failed'

occasionally I get "gateway timeouts" or messages relating to "header
record corrupted".

But this only occurs with the rda.submit calls, any webservice methods
work correctly.

I'm happy that the server is still alive on the internet, if I
immediately fire up pocket ie and browse to the sscesa20.dll it
responds as expected.

As a test I created a new webmethod that would accept the insert
strings normally sent via rda, and when using this, things work fine,
but as soon as I switch back to using rda.submit I get the error (this
can be done on-the-fly in the app using the current/existing
connection). The connection string for this web method is set on the
server.

It's not the rda connection string, since when I use active sync or
local wifi instead of the gprs connection, my gprs methods work fine.

All this testing was done with 'Orange'. At one point, after two hours
of failures, I swapped the sim for a 'Vodafone' one, and it all worked
immediately, but, shortly after that it stopped working. This was all
without making any code or data changes.

Assuming it's not code, where else could I look?

Cheers

Chris

 

[David D Webb]

Hey Chris,

We are currently having very similar problems on this side of the ocean with
US Cingular. Sprint works fine. We are doing all connectivity through
WebRequest/WebResponse objects and just get all kinds of errors back while
connecting - even with 5 bars of signal. I am currently looking for some
type of network diagnostic tool that would give some lower level insight
into what is going on. If anyone knows of such a tool, please let us know.

-Dave

 

[chora]

I have no solution on this, but since we had this problem for a long
time, we discovered that this is a problem between the GPRS carrier, the
ISP provider and sometimes your or your customer's firewall.
Try to find a GPRS carrier that provides also internet connectivity and
start from there. Less problems to face.
BUT, you will NEVER be able to guarantee that GPRS communications will
work with all carriers and all ISPs. It is impossible. Gateways between
carrier and ISP may "confuse" your firewall and reject the connection or
the data.
You will also find out that "older" firewals may work better because
they were less intelligent and less worried about attacks etc, so they
allow incoming data that newer would reject.
I also believe that you have no problem pulling data from your database
right?
So, experiment, find which combinations work for you and that's it.

 

[David W]

We finally figured out it was Cingular's WAP APN that we were using. We
switched to Cingular's other non-WAP APN and things have been much better.
Still slow as dirt, but far fewer timeouts. Sprint's data network seems to
be much better and faster. I wrote a very simple network test application
that has een somewhat helpful. If you are interested in it, email me.