Re: [LARTC] Detecting stale TCP/IP

[Ben Clewett <B.Clewett@roadrunner.uk.com>]

Jasper,

Thanks.  This works absolutelly perfectly!

I found that simply waiting for the TIOCOUTQ to fall to zero gives a 
perfect indication of data having been sent correctly, and if not, that 
the connection is stale.

I have put this into a:

while (test) sleep(1);

But this waists time.  With a ping of 300ms being common, a sleep of 
1000ms is way to much to check every send, so I can only check agregates 
of sending.  Would anybody know of a better method?

Ben

Jasper Spaans wrote:

> On Tue, Jul 29, 2003 at 08:56:24AM +0000, Ben Clewett wrote:
> 
>>Dear lartc,
>>
>>I have a TCP/IP server connecting to a GPRS PDA.
>>
>>Unfortuntatelly GPRS seems unstable, and for this reason or another, a 
>>interupt to the TCP/IP connection (like switching the clinet off 
>>suddenly) does not terminate the TCP/IP connection.  It can still be 
>>seen in 'netstat', and a test by the application shows it present.  It 
>>may time out after about 40 minutes.
>>
>>My real problem is a call to 'write' in non-blocking mode returns 
>>success when the other end of the TCP/IP connection is not there.
>>
>>Does any member know a reference to where I can test for the reply 
>>TCP/IP 'ACK' packet for this write call, and therefore timeout and 
>>terminate the connection?
> 
> 
> You can try using the ioctl TIOCOUTQ, see socket(7). Although this manpage
> states otherwise, at least on 2.4.21 and newer it returns the number of
> unacked bytes.
> 
> Implement a select-loop, and see if the value of this ioctl changes. If not,
> close the connection, and the kernel should handle the rest.
> 
> 
> VrGr,


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/