TCP reset and socket buffer draining responsibility

TCP reset and socket buffer draining responsibility

[John Fieber]

I have a bug where some Rack middleware that determines certain PUT/POST error responses without needing to read the request body.  On Linux, this causes a TCP reset when Unicorn closes the socket with unread data in the input buffer.  The reset preempts the delivery written but still buffered response, so client receives a simple RST and no response.   If I inject some read-buffer draining code just before the close, the problem goes away.

The RST behavior is obviously not desired, but my question is what level of the stack is responsible for making sure it doesn't happen?  It strikes me that Unicorn is in the best position to do it efficiently and reliably, but anything higher up can also do it.

Thoughts?

-john

_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: TCP reset and socket buffer draining responsibility

[Eric Wong]

John Fieber <jfieber@adobe.com> wrote:
> I have a bug where some Rack middleware that determines certain
> PUT/POST error responses without needing to read the request body.  On
> Linux, this causes a TCP reset when Unicorn closes the socket with
> unread data in the input buffer.  The reset preempts the delivery
> written but still buffered response, so client receives a simple RST
> and no response.   If I inject some read-buffer draining code just
> before the close, the problem goes away.
> 
> The RST behavior is obviously not desired, but my question is what
> level of the stack is responsible for making sure it doesn't happen?
> It strikes me that Unicorn is in the best position to do it
> efficiently and reliably, but anything higher up can also do it.

Hi John,

You have to use the read buffer draining code in your app or middleware.

The Unicorn::TeeInput class doesn't read off the socket until it needs
to.  This is because Rack requires the input stream to be rewindable,
and the input stream being rewindable means it must be buffered to a
temporary file which could potentially fill up the disk (especially with
chunked input that doesn't declare a Content-Length).

So Unicorn gives apps/middleware control to cut off uploading clients in
this case.

-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying