[#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: "Daniel Berger" <djberg96@...>
Date: 2006-09-27 02:05:57 UTC
List: ruby-core #8935
On 9/26/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
>
> 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.
>
>
The platform is Solaris 10.

- Dan

In This Thread