PC Review
Forums
Newsgroups
Microsoft DotNet
Microsoft Dot NET Compact Framework
GPRS comms problem - network provider issue?
Forums
Newsgroups
Microsoft DotNet
Microsoft Dot NET Compact Framework
GPRS comms problem - network provider issue?
![]() |
GPRS comms problem - network provider issue? |
|
|
Thread Tools | Rate Thread |
|
|
#1 |
|
Guest
Posts: n/a
|
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 |
|
|
|
#2 |
|
Guest
Posts: n/a
|
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 |
|
|
|
#3 |
|
Guest
Posts: n/a
|
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. *** Sent via Developersdex http://www.developersdex.com *** |
|
|
|
#4 |
|
Guest
Posts: n/a
|
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. "David D Webb" <spivey@nospam.post.com> wrote in message news:uzQJrur0GHA.1548@TK2MSFTNGP02.phx.gbl... > 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 > |
|
![]() |
|
| Thread Tools | |
| Rate This Thread | |
|
|

Main Page 

