Re: Does IO::Select work? Anywhere?

[zentara]

in reply to Does IO::Select work? Anywhere?

I wanted to point you to some code, by ant9000 at $Socket->connected Not Returning False? where he shows how to test $! for socket error codes like EAGAIN. Do you think those sorts of tests on a select socket would be able to detect your "eternal a" script, and dispose of it?

[Anonymous Monk]

I like a magic %! approach, say

use Errno;
sub Fudge {
  my @r;
  while( my($k,$v)=each %!){
    $v and push @r, $k
  }
  join qq/\n/,
    int($!).q/ /.$!,
    int($^E).q/ /.$^E,
    @r, q/ /
}

open my($fh),qw/ < ./ or die Fudge();
__END__
13 Permission denied
5 Access is denied
ERROR_INVALID_DATA
EMR_SETBRUSHORGEX
EACCES
  at - line 13.

[BrowserUk]

Do you think those sorts of tests on a select socket would be able to detect your "eternal a" script, and dispose of it?

The solution is to not use readline, or anything that blocks waits for a terminator that may never arrive.

Instead, use recv or sysread and get whatever is available when can_read() tells you there is something there, and accumulate those somethings until a newline (or other terminator) is seen before taking action.

In the case of the client that never sends a terminator, it will eventually time out if it never transmits anything more.

The most effective DOS strategy against badly written multiplexing servers is to send one character every (say) 890 seconds (default timeouts are often 900), but to never send a terminator.

Another strategy is to send huge packets that overrun memory. For badly designed C code, that usually results in the classic buffer overrun. For a perl program, it can actually be worse. As Perl will just keep increasing the size of the scalar, it can put the server into swapping and bring everything to a crawl without actually blowing it out of the water.

i