[Twisted-Python] twisted gprs
About a year ago we had a look at twisted to do some work with gprs. I got some useful feedback from that. However, it's only now we have had a chance to move things forward. We have done some simple work with wm5/wm6 devices sending GPS data back to a twisted server. And we have done various tests sending/receiving messages over gprs to see what problems we need to overcome. One problem we have right now to which the solution may be obvious but not to us is :-- We have a problem at the server end when we put the pda into 'flight mode'. Thie means that the wireless is switched off and the gprs connection goes away. However, the server does not see this connection go away since the network routers keep the connection up, as far as we can see. In various tests we have the connection take from 2 - 7 mins before a disconnection happens. As far as I can see using 'ethereal', the server decides itself to drop the connection since I do not see a 'FIN' be sent from anywhere. On the server I have set a loopingCall running every 20 seconds, so that I can switch off various parts to see the results. With the pda not connected, the loopingCall keeps on going and sends between 2 -4 messages without getting an ack back from the pda. Then the server stops trying to send any data. The loopingCall keeps going but no data goes out onto the wire. We get upto 16 - 40 loop messages being sent but only the 2-4 go onto the wire. What I would like to be able to do is to not wait 2-7 minutes before realising the connection is not working. I have been through the docs and the api but can't find anything that I can use. Is there any call I can make use of to be able to detect the failed send before the connection finally is broken. Thanks for any help on this. John Aherne
What I would like to be able to do is to not wait 2-7 minutes before realising the connection is not working.
I have been through the docs and the api but can't find anything that I can use.
Is there any call I can make use of to be able to detect the failed send before the connection finally is broken.
I assume this is TCP. What you're seeing is TCP in action. You send data until you fill the TCP window, then the kernel queues the data, then TCP times out. If you want a faster timeout, you'll need to add application level ACKs, and add a timeout on those, or tune your kernel to have shorter TCP timeouts. You _may_ be able to call getsockopt() and check the outgoing buffer size to determine that there is unsent data, but I don't think you can detect unack'd data (if anyone knows a way, please speak up). -- Carson
Carson Thanks for the info. I have since read up on TCP and see that I am looking at standard TCP comms. But I don't want to do anything too tricky. Just standard twisted if possible. I'll have to take a lok at doing my own timeouts with a callLater to see if I get a response. If that makes sense. Thanks John Aherne -----Original Message----- From: twisted-python-bounces@twistedmatrix.com [mailto:twisted-python-bounces@twistedmatrix.com]On Behalf Of Gaspar, Carson Sent: 09 January 2008 22:55 To: Twisted general discussion Subject: RE: [Twisted-Python] twisted gprs
What I would like to be able to do is to not wait 2-7 minutes before realising the connection is not working.
I have been through the docs and the api but can't find anything that I can use.
Is there any call I can make use of to be able to detect the failed send before the connection finally is broken.
I assume this is TCP. What you're seeing is TCP in action. You send data until you fill the TCP window, then the kernel queues the data, then TCP times out. If you want a faster timeout, you'll need to add application level ACKs, and add a timeout on those, or tune your kernel to have shorter TCP timeouts. You _may_ be able to call getsockopt() and check the outgoing buffer size to determine that there is unsent data, but I don't think you can detect unack'd data (if anyone knows a way, please speak up). -- Carson _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Is there any call I can make use of to be able to detect the failed send before the connection finally is broken. In general, there is no way to know if a connection is broken. The standard way to do this is to send a heartbeat message every x seconds if there is no other communication on the connection. On the server, you keep a watchdog timer and wait 2x seconds. You reset
John Aherne wrote: the timer on every communication. This can be tuned as you see fit, but it has to be done in your application. The trade off is that if you want to know instantly that a connection is down, you need to be sending data constantly. Carson suggested some ways to tweek TCP, and if you have control of the TCP stack, it is tweakable, but it is not portable. Carl zmola@acm.org
Is there any call I can make use of to be able to detect the failed send before the connection finally is broken. In general, there is no way to know if a connection is broken. The standard way to do this is to send a heartbeat message every x seconds if there is no other communication on the connection. On the server, you keep a watchdog timer and wait 2x seconds. You reset
Carl Thanks for the reply. I see now. I did take a look at the TCP book and see what you mean. What I am trying to do is:-- I have a GPS app on the pda that can transmit every 30 secs or some other parameterised time frame. This uses a port of its own. I have another app on the same pda that receives ad hoc messages from the server and acknowledges these with a message. This is done on a different port. For the pda app that waits for messages from the server, I hold a dict of connections to talk back on. If the pda can't receive I would like to report back very quickly that it is not connected. In theory, if I transmit gps every 30 secs that will keep the connection open from the pda and is in effect a keepalive. Except when someone is in a basement or tunnel when the gprs might disappear. One thought I had was to do a callLater on the server of say 30secs once I had sent the message, and check whether I had seen a response to that message within the timeframe. If not I could drop the connection from my dict and wait for the pda to reconnect with maybe a different IP and port. Since the gps is send only from the pda I am not too worried if that fails every now and then. It can just reconnect as and when. I assume that what I am suggesting is a version of application acks as you mention. Just nice if someone could confirm that it makes some sense. Once again Thanks. John Aherne -----Original Message----- From: twisted-python-bounces@twistedmatrix.com [mailto:twisted-python-bounces@twistedmatrix.com]On Behalf Of Carl Zmola Sent: 10 January 2008 00:06 To: Twisted general discussion Subject: Re: [Twisted-Python] twisted gprs John Aherne wrote: the timer on every communication. This can be tuned as you see fit, but it has to be done in your application. The trade off is that if you want to know instantly that a connection is down, you need to be sending data constantly. Carson suggested some ways to tweek TCP, and if you have control of the TCP stack, it is tweakable, but it is not portable. Carl zmola@acm.org _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
participants (3)
-
Carl Zmola -
Gaspar, Carson -
John Aherne