tcp socket problem

Dan Stromberg dstromberglists at gmail.com
Sat Jul 26 16:41:15 EDT 2008


On Fri, 25 Jul 2008 16:09:13 -0700, jm.carp wrote:

> I'm writing a tcp client that grabs data from a server at 32hz. But the
> connection drops exactly one minute after it's opened. I can get data
> from the server fine for the first 60s, and then the connection goes
> dead. What's going on?

What does "goes dead" mean in this case?  Is python giving a traceback?  
Is some I/O blocking?

I'd probably use a system call tracer to track down something like that, 
unless there's a useful traceback.  It may be useful in the client, or 
the server, or both.

http://stromberg.dnsalias.org/~strombrg/debugging-with-syscall-
tracers.html

Also, be careful to check that you aren't reading two chunks when you 
think you're getting one or something.  That could cause some I/O to 
block in a hard-to-track-down way.  IOW, TCP feels free to chop your 
packets into multiple packets, or to aggregate multiple packets into a 
smaller number of them - whatever it wants, pretty much.  This sometimes 
helps performance or reliability, but it complicates writing socket 
programs at times.  Put another way, a single send might show up as two 
recv's, for example.

Oh, and using a sniffer may help too.  I like wireshark or tshark (GUI 
and text interfaces of the same underlying sniffer), but there are many 
available.  Old hands seem to prefer tcpdump, though I'm clear on why.  
If you fire up a sniffer against your network communication, it should be 
possible to see, for example, the last packet transferred, which system 
it was to, and which system it was from. You may not know which host is 
having the problem without a detailed knowledge of the protocol, but 
since you're coding the program, you may  have that.  :)  This may show 
packet splitting/aggregation too, but keep in mind that a sniffer only 
shows you the data stream at a particular point in the transfer - you 
could see different things when running a sniffer on the client, on the 
server, or even on a subnet in between the two.  Oh, and many networks 
are switched now, so most sniffers don't do that well on subnets in 
between, but they frequently still work well on the client and server 
themselves.

HTH



.



More information about the Python-list mailing list