Eero, I came across this (http://www.cl.cam.ac.uk/~rc277/globe02.pdf).
It would appear that a cellular device could have issue with receiving data because it temporarily goes out of range or has some other issue which causes packets to "back up" at the GPRS device. From the above document it looks like it could take up to a minute before that backlog is cleared up. Have you tried waiting around for a while to see if the ping packet eventually makes it to the device? If it does make it "eventually" you could decrease your ping send interval while simultaneously increasing the time you wait for a ping response. Unfortunately this means your connection could go down for a little while before you notice it, but at least you'd have something that lets you know the connection is bad eventually. Another consideration may be the infamous naggle algorithm. You can of course turn it off on your server application and on your client as well. Unfortunately you have no control on whether the GPRS is using naggle for it's connection to the cellular device. Have you tried sending a lot of ping packets? This is of course wasteful, but if you send approximately 1500 bytes worth of ping data and miraculously they all arrive at the device at once naggle, or something equally nefarious, is probably the cause. Be aware that 1500 bytes or so is the usual Maximum Transmission Unit on most LAN's by default, but this can be changed easily and may very likely be different on the cellular network. I'd try sending multiple ping packets slowly (like 1 every 30 seconds to one minute) and see how many you have sent before the first one arrives. When the first one arrives you'll probably get a bunch of them together at once. Try to count how many arrive at once (or in very rapid succession) and then try sending that many ping packets + 1 more all at once from your server. If your rapid fire of multiple pings works more reliably one solution may simply be to send artifically large ping packets. By fine tuning the packet size of your ping message you may be able to more reliably circumvent the "grouping" of naggle and similar approaches. Whatever you find is the "sweet spot" for packet size you may want to increase it slightly so on other networks with potentially larger MTU sizes your application still works. Again, this is all wasteful from a bandwidth perspective - especially when end-users are charged per MB of data transfer on some cell networks, but at least it would be a working solution. Please report your findings back to the list, or at least to me. I'd be very interested in the results. Thanks! Rob ----- Original Message ---- From: Eero Nevalainen <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, May 11, 2007 7:30:32 AM Subject: Re: Session close problem Hi all, I've recently deployed a gateway server to mediate communication between clients and remote devices. The gateway works fine in a 'regular' network, but now we're experiencing problems when the remote devices are behind a GPRS network. The gateway sends an application level (TCP) 'PING' message periodically to the remote devices. For some reason the PING messages seem to queue up in the GPRS connection, without the devices receiving them. Meanwhile, sending an ICMP request to the same devices gives a much smaller roundtrip time (~700ms) and no message losses. Also the messages sent by the remote devices to the gateway always arrive properly. I can't reproduce this problem with an ethernet connection so any help with the GPRS network would be most welcome! -Eero Nevalainen Dawie Malan wrote: > You're quite right - there is something in the middle, and it does cause the > symptoms you are reporting. > > A GPRS network has two essential elements: > > *Serving GPRS Support Node (SGSN)-Sends data to and receives data from mobile > stations, and maintains information about the location of a mobile station > (MS). > The SGSN communicates between the MS and the GGSN. > > *Gateway GPRS Support Node (GGSN)-A wireless gateway that allows mobile cell > phone users to access the public data network (PDN) or specified private IP > networks. > > The GGSN acts like a proxy and is the device that sends the ACKs to the phone > even though the session is already closed on the server side. > > I hope this answers your question. > > Regards, > > Dawie Malan > > > -----Original Message----- > From: Michael Bauroth [mailto:[EMAIL PROTECTED] > Sent: 22 March 2007 04:40 PM > To: [email protected] > Subject: Session close problem > > Hi, > > I'm using currently the trunk version of Mina. I use it to communicate > with GPRS devices on the other side. In most cases this works very well! > > But sometimes the things become strange. I've collected a bunch of > problems where I would need help / advices / ideas. > > 1. I call session.close() from inside my server. It seems, that the > session doesn't close as required. > > 2. I close the session. The GPRS device on the other side continues to > send data and seems to get ACKs too. It doesn't recognize, that the > other side of the connection (the server) has closed the session a while > before. It seems that there is something in the middle which responds > the ACKs even with not opened server session. > > Knows anybody one of the two (most painful) problems and has an answer > for me? > > Best Regards > Michael > > > ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/
