[#8815] Segfault in libc strlen, via rb_str_new2 — "Sean E. Russell" <ser@...>

Howdy,

12 messages 2006/09/09
[#8817] Re: Segfault in libc strlen, via rb_str_new2 — Eric Hodel <drbrain@...7.net> 2006/09/09

On Sep 8, 2006, at 10:10 PM, Sean E. Russell wrote:

Re: RDoc patch, possible bug in socket.c for TCPSocket.new

From: "Francis Cianfrocca" <garbagecat10@...>
Date: 2006-09-26 23:46:22 UTC
List: ruby-core #8933
On 9/26/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
>
>
> This is the normal behavior for a TCP session.  After the server
> sends the
> final ACK to the client, the TCP session must remain in the TIME_WAIT
> state
> for twice the maximum segment lifetime.  The delay is to handle lost
> acks,
> or stray duplicate segments that arrive after the session has been
> closed.  It
> is the kernel that takes care of this housekeeping.


A little more: TIME_WAIT is only incurred by the side of the connection that
initiates the connection teardown. In your example, that would be the
client-side. What surprises me about this example is that some kernels don't
bother with TIME_WAIT when both client and server are localhost, because the
kernel is in a position to know for sure whether any data belonging to the
connection is still floating around. So I was also curious about the
platform Daniel is running this on.

In This Thread