Re: TCP reset caused by socket.py

On Dec 11, 6:17 pm, "Gabriel Genellina" <gagsl-...@xxxxxxxxxxxx>
wrote:
En Tue, 11 Dec 2007 10:51:13 -0300, Object01 <objec...@xxxxxxxxx> escribi�:

I've been working with the source code for Trac (http://
trac.edgewall.org/) lately and have run across a bizarre problem. It
seems that all POST requests to Trac's standalone server (tracd) have
a random chance of causing the server to issue a TCP RST packet that
resets the connection.

Running Trac 10.3.1 on Win2K3 using Python 2.4, watching traffic with
Wireshark 0.99.5.

I've been stepping through the code using Winpdb 1.3.2 and have
isolated the problem to the socket.py that's included in Python 2.4.
Line 157, in _socketobject.close():

self.send = self.recv = self.sendto = self.recvfrom =
self._sock._dummy

is what's causing the TCP RST to be issued. If I set a breakpoint on
that line and step over it on a POST request, there's about an 80%
chance the server will issue a TCP RST. When debugging, the entire
response makes it onto the wire before TCP RST is issued. If I'm -
not- debugging, it's anybody's guess as to how much of the response
makes it out. The interruption, when it occurs, always seems to be
between calls to _fileobject.write(). This indicates a timing issue:
perhaps buffered data isn't being waited on properly prior to
the .close() method doing its work.

I think the trigger is the line just above that, where the "real" socket
is deleted. A RST when you close a socket is OK. From your description it
appears that the close method should not have been called at that time;
I'd look at the stack and see why is it being called when it shouldn't.

I don't believe Python itself randomly calls close() so it looks like a
Trac problem, or in the webserver used. Is there any timer used? Is the
server multithreaded?

--
Gabriel Genellina

The server is multithreaded, handling each request on its own thread.
But is a RST really a part of a valid close operation? 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.

Looking at the stack, it appears the socket is being closed at the
right time. All data has been sent and the request handler is in its
tear-down phase, expecting no more data from the client (who never
sends any). I don't see different stack traces between error and no-
error requests.

And on line 156, how is the real socket being deleted? It (the _sock
member) appears to be set to a dummy class that has no real
functionality.

--
Jeff S.
.

Relevant Pages

  • SERVICE_CONTROL_STOP not received
    ... the ServiceMainwill start a socket ... The socket server is wrapped in a class ... is "Wait" and the reason is "User Request") ... SERVICE_CONTRL_STOP or other control messages from SCM? ...
    (microsoft.public.win32.programmer.kernel)
  • Re: IPC looking for simple/best way to communicate
    ... want to go to a server/client connection. ... Server accepts connections on given port. ... request or a request with a removal. ... >> one process reads a socket it removes the message from the socket and ...
    (comp.lang.perl.misc)
  • IE6 bug: doesnt resend form-data when server resets connection
    ... When the server closes the connection on a socket where IE is currently ... sends the request on an existing socket and the server immediately replies ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: HowTo, Download first 1024 bytes of file ONLY?
    ... (most of which was stolen from a Microsoft C# socket example) ... string server = SERVER_NAME; ... // Send request to the server. ... after 3-full days of performing errant google searches). ...
    (microsoft.public.dotnet.framework)
  • Re: Socket weirdness
    ... If RST is at the top of the stack before the ... RST is not "seen" by the client until the first ACK to client *after ... a Shutdown.Receive by the server. ... some N factor of stocks or time and closes socket. ...
    (microsoft.public.dotnet.framework)