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 . -- http://mail.python.org/mailman/listinfo/python-list
