netdev
[Top] [All Lists]

Re: [PATCH] connect() return value.

To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: [PATCH] connect() return value.
From: Geoffrey Lee <glee@xxxxxxxxxxxxxxx>
Date: Fri, 16 Aug 2002 11:08:09 +1000
Cc: kuznet@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20020815.142337.95077599.davem@redhat.com>
References: <20020815032543.GA3083@gandalf.chinesecodefoo.org> <20020814.201514.30457132.davem@redhat.com> <20020815110210.GA15218@anakin.wychk.org> <20020815.142337.95077599.davem@redhat.com>
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mutt/1.4i
On Thu, Aug 15, 2002 at 02:23:37PM -0700, David S. Miller wrote:
>    From: Geoffrey Lee <glee@xxxxxxxxxxxxxxx>
>    Date: Thu, 15 Aug 2002 21:02:10 +1000
> 
>    On Wed, Aug 14, 2002 at 08:15:14PM -0700, David S. Miller wrote:
>    > How extensive are your notes on poll() behavior on TCP
>    > sockets? :-)
> 
>    Hmm, in which regard?
>    
>    Is there something specific that you are searching for? :-)
> 
> POLLHUP in particular.  I remember we verified that our behavior
> matched Solaris but no checks were performed against others.


In all honesty, none for that. But it would be a worthwhile experiment
I think. Let us see what happens.


Today, we are going to see what happens with POLLHUP on different Unix
implementations. Source code is provided.

poll.c (server that uses poll)
linger.c (our client to invoke the POLLHUP condition)

Note in poll.c I used size_t as the 3rd argument to accept instead
of socklen_t, as only Linux had socklen_t.

We also see that we get a compile warning when compiling the client as
on SunOS 5.6 the 4th argument to setsockopt is a char *. But we can
ignore that warning.


The following operating systems will be tested against:

OSF1 4.0 (Digital UNIX)
SunOS 5.6 (Solaris)
Linux 2.4.18


We will start the server on a machine with some specified port. We 
call listen for the specified socket, and accept. Next, we block
in the call to poll with fd set to the socket descriptor returned
by accept, and events and revents zeroed. On the call to poll, we 
specify -1 as a senitel that we want to block forever until something
interesting arrives (the error condition).

On the client, we connect to the server to the specified port
as normal. We specify the SO_LINGER option, with l_onoff set to 1 and
linger time set to 0. After we successfully connect to the server, we
call the close call immediately, to issue a RST to the server.


This is what happens on Linux 2.4.18:

$ ./poll -p 8888 
accept ok.
poll: POLLERR set
poll: POLLHUP set
sever terminating
$ 

On the client side:

$ ./linger -h [ip] -p 8888
connecting ..
closing ...
closed.
$ 


So, sending a RST will trigger POLLHUP and POLLERR on Linux.


On OSF1 4.0, we get this:

On the server:
$ ./poll -p 8888
accept ok.

On the client side:
$ ./linger -h [ip] -p 8888
connecting ..
closing ...
closed.
$ 


So on Digital UNIX, it blocks forever in the call to poll.

That's strange. Let's see what happens on SunOS 5.6:

./poll -p 8888
accept ok.


On the client side:

./linger -h [ip] -p 8888
connecting ..
closing ...
closed.
$ 


So on SunOS 5.6, it also blocks forever.


Do you know which Solaris was tested the last time it was found that
Linux behaves the same way as Solaris?

By the way, while we are on the subject of poll, what should one include
to get POLLRDNORM and INFTIM?

I found on OSF1 4.0 one can have both by including <poll.h>,
on SunOS 5.6, one can get POLLRDNORM by including <poll.h>, for INFTIM,
one must include <sys/stropts.h> as well.

On Linux, one will not be able to get them by including both <poll.h>
or <sys/stropts.h>. <sys/poll.h> will not work either. by including 
<linux/poll.h>, then one can get POLLRDNORM defined. But I could not
find INFTIM anywhere on Linux.


        -- G.


Attachment: linger.c
Description: Text Data

Attachment: poll.c
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>