Do you have any non-standard network hardware along the route? Perhaps a transparent proxy like a load balancer or a firewall of sorts? I've seen this type of thing happen before with load balancer gear. In my situation, I had a load balancer that kept a state table. If the load balancer didn't see client-side traffic within a 5 second period, it would terminate the connection by sending some out of sequence data that generated the RST. We spent half a day tracking down (what we thought was) a bug in one of our Apache modules and it turned out to simply be a configurable timeout value.
On 12/12/07, Object01 <[EMAIL PROTECTED]> wrote: > > On Dec 12, 12:45 pm, Bjoern Schliessmann <usenet- > [EMAIL PROTECTED]> wrote: > > Object01 wrote: > > > The server is multithreaded, handling each request on its own > > > thread. > > > > Ugh. > > > > > But is a RST really a part of a valid close operation? > > > > Depends on the state of the parties :) The proper way to close > > non-defunct connections is using FIN segments. > > > > > It was my understanding that the RST is used to indicate a problem > > > with the connection, usually a half-open connection. I never see > > > RSTs unless this error occurs. > > > > RFC793: > > > > | Reset Generation > > | > > | As a general rule, reset (RST) must be sent whenever a segment > > | arrives which apparently is not intended for the current > > | connection. A reset must not be sent if it is not clear that this > > | is the case. > > > > Regards, > > > > Björn > > > > -- > > BOFH excuse #347: > > > > The rubber band broke > > Is there something I can look for in the packet traffic that would > indicate one party is misbehaving? The sequence numbers seem ok. > *shrug* I'd expect to see data sent from server to client and then > see a sequence of packets that close the connection gracefully. > Instead I see the server send data to the client and then a RST, > nothing more. > > The crux of this strangeness seems to be Python sending a RST without > any prompting from the client. It's just send to client, send to > client, send to client, reset. OH! Maybe the client isn't > acknowledging properly or the server is incorrectly expecting > acknowledgment and resets when it doesn't arrive? > > Rrr... > > -- > Jeff S. > -- > http://mail.python.org/mailman/listinfo/python-list >
-- http://mail.python.org/mailman/listinfo/python-list
