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

Hi,

I just recently discovered that TCPSocket.new actually
accepts up to four
arguments.  Here's an attempt at an rdoc patch, but perhaps
someone can do a
better job of explaining it:

--- socket.orig Tue Sep 26 12:58:49 2006
+++ socket.c    Tue Sep 26 13:06:44 2006
 -1274,6
+1274,14 
                     inetsock_cleanup, (VALUE)&arg);
 }

+/*
+ * call-seq:
+ *    TCPSocket.new(remote_host, remote_port,
local_host=nil,
local_port=nil)
+ *
+ * Opens a TCP connection to +remote_host+ on
+remote_port+.  If
+local_host+
+ * and +local_port+ are specified, then those parameters
are used on the
local
+ * end to establish the connection.
+ */
 static VALUE
 tcp_init(argc, argv, sock)
      int argc;

I'm not entirely positive what happens if you specify a
local_host without a
local_port, so perhaps someone can clear that up.

Also, I think there's a bug with the local connection not
closing properly.
The local connection appears to go into a TIME_WAIT, and it
looks to me like
it's the OS that finally closes it out.   Here's a short
program to
demonstrate:

require 'socket'

socket = TCPSocket.new('localhost', 23, 'localhost', 8885)
sleep 20
socket.close

When I do a quick check of netstat -a, I see this:

localhost.8885       localhost.telnet     49152      0 49152
     0
ESTABLISHED
localhost.telnet     localhost.8885       49152      0 49152
     0
ESTABLISHED

However, after the program has finished, I see this:

localhost.8885       localhost.telnet     49152      0 49152
     0
TIME_WAIT

Also, if I try to connect while it's in a TIME_WAIT state, I
get this:

tcpsocket.rb:5:in `initialize': Address family not supported
by protocol
family - bind(2) (Errno::EAFNOSUPPORT)
        from tcpsocket.rb:5

That error doesn't appear correct to me.  I would expect an
in-use error of
some sort maybe.

I believe Nobu had a patch for this back in *http://tinyurl.com/k7oyr* but
I'm not sure it was ever applied.


Regards,

Dan

Daniel Berger wrote:
> Hi,
> 
> I just recently discovered that TCPSocket.new actually
accepts up to four
> arguments.  Here's an attempt at an rdoc patch, but
perhaps someone can 
> do a
> better job of explaining it:

<snip>

Here's the patch again, without the bad formatting from
gmail, but with the 
corporate disclaimer:

--- socket.orig Tue Sep 26 12:58:49 2006
+++ socket.c    Tue Sep 26 13:06:44 2006
 -1274,6
+1274,14 
                      inetsock_cleanup, (VALUE)&arg);
  }

+/*
+ * call-seq:
+ *    TCPSocket.new(remote_host, remote_port,
local_host=nil, local_port=nil)
+ *
+ * Opens a TCP connection to +remote_host+ on
+remote_port+.  If +local_host+
+ * and +local_port+ are specified, then those parameters
are used on the local
+ * end to establish the connection.
+ */
  static VALUE
  tcp_init(argc, argv, sock)
       int argc;

Regards,

Dan


This communication is the property of Qwest and may contain
confidential or
privileged information. Unauthorized use of this
communication is strictly 
prohibited and may be unlawful.  If you have received this
communication 
in error, please immediately notify the sender by reply
e-mail and destroy 
all copies of the communication and any attachments.

On Sep 26, 2006, at 3:26 PM, Daniel Berger wrote:
> Also, I think there's a bug with the local connection
not closing  
> properly.
> The local connection appears to go into a TIME_WAIT,
and it looks  
> to me like
> it's the OS that finally closes it out.   Here's a
short program to
> demonstrate:

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.

See Stevens, TCP/IP Illustrated V1 p 242 for details.

> Also, if I try to connect while it's in a TIME_WAIT
state, I get this:
>
> tcpsocket.rb:5:in `initialize': Address family not
supported by  
> protocol
> family - bind(2) (Errno::EAFNOSUPPORT)
>        from tcpsocket.rb:5

Is this an error from the client trying to connect to the
server in  
the TIME_WAIT
state or is this the error you are getting from the server
trying to  
restart and
bind and reuse the local port that is still in the TIME_WAIT
state?

You use of the word 'connect' is a bit confusing since that
is not  
generally used
to describe the behavior of a TCP server.

Gary Wright

gwtmp01mac.com wrote:
> 
> On Sep 26, 2006, at 3:26 PM, Daniel Berger wrote:
>> Also, I think there's a bug with the local
connection not closing 
>> properly.
>> The local connection appears to go into a
TIME_WAIT, and it looks to 
>> me like
>> it's the OS that finally closes it out.   Here's a
short program to
>> demonstrate:
> 
> 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.
> 
> See Stevens, TCP/IP Illustrated V1 p 242 for details.

Ok, thanks.

>> Also, if I try to connect while it's in a TIME_WAIT
state, I get this:
>>
>> tcpsocket.rb:5:in `initialize': Address family not
supported by protocol
>> family - bind(2) (Errno::EAFNOSUPPORT)
>>        from tcpsocket.rb:5
> 
> Is this an error from the client trying to connect to
the server in the 
> TIME_WAIT
> state or is this the error you are getting from the
server trying to 
> restart and
> bind and reuse the local port that is still in the
TIME_WAIT state?

I get that error if I try to run the same script again
before the OS has closed 
the connection.  I'm expecting an error, just not *that*
error.  It's not a 
major issue, mind you.  I just thought it was odd.

> You use of the word 'connect' is a bit confusing since
that is not 
> generally used
> to describe the behavior of a TCP server.

I'm not sure where you mean? In my rdoc patch? I'm sure it
could use 
improvement - I'm hoping people on the list can improve the
wording.

Regards,

Dan

PS - My apologies for the corporate disclaimer.  I'll try to
setup my gmail 
account through my email client at work.  Hopefully, I'll be
able to post 
without the disclaimer and the sucky formatting.


This communication is the property of Qwest and may contain
confidential or
privileged information. Unauthorized use of this
communication is strictly 
prohibited and may be unlawful.  If you have received this
communication 
in error, please immediately notify the sender by reply
e-mail and destroy 
all copies of the communication and any attachments.

On Sep 26, 2006, at 5:35 PM, Daniel Berger wrote:
>>> Also, if I try to connect while it's in a
TIME_WAIT state, I get  
>>> this:
>>>
>>> tcpsocket.rb:5:in `initialize': Address family
not supported by  
>>> protocol
>>> family - bind(2) (Errno::EAFNOSUPPORT)
>>>        from tcpsocket.rb:5
>> Is this an error from the client trying to connect
to the server  
>> in the TIME_WAIT
>> state or is this the error you are getting from the
server trying  
>> to restart and
>> bind and reuse the local port that is still in the
TIME_WAIT state?
>
> I get that error if I try to run the same script again
before the  
> OS has closed the connection.  I'm expecting an error,
just not  
> *that* error.  It's not a major issue, mind you.  I
just thought it  
> was odd.
>
>> You use of the word 'connect' is a bit confusing
since that is not  
>> generally used
>> to describe the behavior of a TCP server.
>
> I'm not sure where you mean? In my rdoc patch? I'm sure
it could  
> use improvement - I'm hoping people on the list can
improve the  
> wording.

I was a bit confused.  I was thinking your code implemented
a server  
but you were coding a client establishing a connection to a
local  
telnet server.  So when you said 'if I try to connect', I  
misunderstood you.

My comments regarding TIME_WAIT still apply.

Normally a client program does not specify a local port and
the  
kernel picks an ephemeral port number for each connection. 
In this  
case when you restart the client the kernel picks a
different  
(unused) ephemeral port, you don't end up using the same
(remote  
host,remote port, local host, local port) tuple and so you
don't have  
a conflict with the previous TCP session which is still in
the  
TIME_WAIT state.

If you explicitly choose a local host and local port then
when you  
restart the client you'll be in conflict with the previous
session  
and should get a something like an EADDRINUSE error, which
is what I  
get on Mac OS X when I repeated your example (ruby 1.8.5).

So normally a client doesn't have a problem with TIME_WAIT
because it  
uses a different port each time but a *server* that is
stopped and  
restarted quickly can have a problem with TIME_WAIT because
a server  
almost always binds to an explicit port (80 for an web
server, for  
example).

What OS are you testing this on that you get an EAFNOSUPPORT
error  
when you rerun the program before the TIME_WAIT expires?


Gary Wright

On 9/26/06, gwtmp01mac.com <gwtmp01mac.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.

On 9/26/06, Francis Cianfrocca <garbagecat10gmail.com> wrote:
>
> On 9/26/06, gwtmp01mac.com <gwtmp01mac.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

On Sep 26, 2006, at 7:46 PM, Francis Cianfrocca wrote:
> 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.

On Mac OS I can't see the session sitting in TIME_WAIT via
netstat but I
do get EADDRINUSE if I try to re-establish the session
during the  
2MSL delay.
Strange.