PERL Beginners - IO::Socket squirreliness

Author

IO::Socket squirreliness

Mason Loring Bliss

2005-08-23, 6:56 pm

Hi, all! I'm learning about dealing with sockets in Perl, and I've got a
question about some unexpected behaviour exhibited by the following test
script.

In the case where I open a connection and then close it before
$socket->accept() is called, I'd except $socket->accept() to return undef,
but it never does. Will someone kindly tell me why this is?

Thanks in advance!

#!/usr/bin/perl

use strict;
use warnings;

use IO::Select;
use IO::Socket;

my $socket = IO::Socket::INET->new(
"Proto" => "tcp",
"LocalPort" => "31337",
"Listen" => SOMAXCONN,
"Blocking" => 0) or die "Ah! Bugger!\n";
$socket->autoflush(1);

my $select = IO::Select->new();
$select->add($socket);

while (1) {
# Accept new connections. Won't bother to process more than one
# per loop iteration.
my @can_read = $select->can_read(0);
if (scalar @can_read > 0) {
print "Connection found...\n";
print " Sleeping five seconds.\n";
sleep 5;
my $client = $socket->accept();
if (not defined $client) {
print " Didn't work out!";
next;
}
print " Accepted!\n";
}
}

--
Mason Loring Bliss mason@blisses.org http://blisses.org/
"I am a brother of jackals, and a companion of ostriches." (Job 30 : 29)

Mason Loring Bliss

2005-08-24, 6:56 pm

On Tue, Aug 23, 2005 at 11:10:58AM -0400, Mason Loring Bliss wrote:

> Hi, all! I'm learning about dealing with sockets in Perl, and I've got a
> question about some unexpected behaviour exhibited by the following test
> script.
>
> In the case where I open a connection and then close it before
> $socket->accept() is called, I'd expect $socket->accept() to return undef,
> but it never does. Will someone kindly tell me why this is?
>
> Thanks in advance!

Is there a forum other than this one where I might ask this question? I
was hoping that maybe someone here knew the answer and would share it...

Should $socket->accept() return undef if the client in question has died
off before the server has gotten around to accepting() the connection?
Maybe my assumption is faulty, and there's no implicit close happening
when the initiating process dies. I'll explore this possibility.

Hm. No. When the client calls shutdown(2) or close() before the server
calls accept(), the server's $socket->accept still returns with a socket,
and not undef.

Am I missing something fundamental here? Is this a bug in IO::Socket? Is
there some other issue of which I'm unaware?

Thanks in advance for enlightening me.

--
Mason Loring Bliss mason@blisses.org http://blisses.org/
"I am a brother of jackals, and a companion of ostriches." (Job 30 : 29)

Bob Showalter

2005-08-24, 6:56 pm

Mason Loring Bliss wrote:
> On Tue, Aug 23, 2005 at 11:10:58AM -0400, Mason Loring Bliss wrote:
>
>
> Is there a forum other than this one where I might ask this question?
> I was hoping that maybe someone here knew the answer and would share
> it...
>
> Should $socket->accept() return undef if the client in question has
> died off before the server has gotten around to accepting() the
> connection? Maybe my assumption is faulty, and there's no implicit
> close happening when the initiating process dies. I'll explore this
> possibility.
>
> Hm. No. When the client calls shutdown(2) or close() before the server
> calls accept(), the server's $socket->accept still returns with a
> socket, and not undef.
>
> Am I missing something fundamental here? Is this a bug in IO::Socket?
> Is there some other issue of which I'm unaware?

I don't think there's any problem with IO::Socket. Even if accept returns a
socket, you should receive an EOF on that socket when you try to read from
it, which tells you that the peer has closed the connection. I think you
just need to check for both situations: an error from accept(), and EOF from
read().

Bob Showalter

2005-08-24, 6:56 pm

Bob Showalter wrote:
> I don't think there's any problem with IO::Socket. Even if accept
> returns a socket, you should receive an EOF on that socket when you
> try to read from it, which tells you that the peer has closed the
> connection. I think you just need to check for both situations: an
> error from accept(), and EOF from read().

Another way of looking at it is to suppose that the client connected, sent a
small message, and then disconnected before you called accept(). The kernel
could still maintain this data in its buffers, and you would obviously need
accept to return the socket so you could read the data.

A connect() followed by a close() is just another form of this scenario. You
need to have a client socket in order to detect the peer's closing the
connection.

Mason Loring Bliss

2005-08-25, 9:55 pm

On Wed, Aug 24, 2005 at 04:14:15PM -0400, Bob Showalter wrote:

> A connect() followed by a close() is just another form of this scenario. You
> need to have a client socket in order to detect the peer's closing the
> connection.

That clarifies things quite nicely. Thank you very much!

--
Mason Loring Bliss mason@blisses.org http://blisses.org/
"I am a brother of jackals, and a companion of ostriches." (Job 30 : 29)

Sponsored Links