You have no else block on the if (sysread($ircsock, $ircdata, 512)) { block, so you don't handle the case where the server closes the connection at all, which results in exactly the loop you're seeing.

As to why the server would close the socket when one of your clients disconnects, that may be because of the way the client is disconnecting. Most IRC clients will send a QUIT command to the server when they're about to disconnect, and I wouldn't be surprised if this causes the server to actively close the connection.

Since you don't do any special processing for the QUIT command, I suspect that as soon as one of your clients exits it will cause the server to close the connection to your "proxy". A possible workaround would be to intercept all QUIT commands and just ignore them.

On an unrelated note, I think your usage of sysread will get you into trouble. After each sysread you appear to expect that the result of a successful read will be a complete line. However there's nothing preventing sysread from returning half a line, or two lines at once.

LOL.. Where were you when I needed you! :-) The intercept of the QUIT was exactly the problem. Soon after ikegami's last post I went back to the code and noticed I was letting the QUIT from the client get through to the server. I had to join the irc server with a different client directly and watch the proxy user quit when it's client quit which was not suppose to happen. That is when I realized I was never trapping and processing the QUIT from the client.

As for the else, I suppose I could add a simple "exit(0)" in an else there but I never expect the server socket to close. It is bad practice to not handle it if it does though so thanks for pointing it out.

wrt sysread, are you talking about the regex that looks for : at the begining of the buffer read? Are you saying that maybe this will fail if sysread reads 1 and 1/2 lines and then the second half of the second line in the next call? I can see your point if that is what you are talking about. Is there another way of reading from a socket that will ensure at least a complete line with each read? Possibly a slurp style read (<$ircsock>)?

I think what you really want to do (since your ircsocket might lose connection for any number of reasons like an irc server restart), is to just reopen the socket. I.e. something like this:

if ($fh == $ircsock) {
  ...
  if (sysread($ircsock, $ircdata, 512)) {
     ...
  } else {
    $sel->remove($ircsock);
    close($ircsock);
    ...reopen $ircsock...
    ...add $ircsock to $sel...
  }
[download]

As for the sysread issue, I'm talking not just about that regex but also the rest of them. For example when you have your /^JOIN\s*\#(\S+)/ regex. If the sysread returns something like JOIN #test\nJOIN #blah, your code will silently ignore the second command.

A slurpy read is one way to solve it, and for IRC this will probably work fine since the IRC protocol is linebased.

In general, it may be better to do something like:

my $clientdata = "";

while (1) {
  #-- Add the new data at the end of the existing one
  sysread $fh, $clientdata, 512, length $ircdata;

  #-- See if we have a full line we can process
  while ($fh =~ s/^(.*?)\r?\n//) {
  my $line = $1;

  ... do your per-line regex stuff here...
  }
}
[download]

This means of course that in your case you need to keep track of $clientdata on a per-filehandle basis (have something like an %clientdata hash keyed on the filehandle). And of course you wouldn't have the while (1) in your code.

Update: A few more ways in which your current sysread code can go wrong: if the server sends a >512 byte line, you will send this to your clients as two lines with a newline inbetween, because you unconditionally add a \n after your print to the clients. In this particular case you're probably better off just removing the chomp($ircdata) and print the string to the clients as-is.

Your current code also silently drops server messages to clients that can't currently receive them. This may be what you intended of course.

One last issue I forgot is your use of \n to terminate lines you send to the server (i.e. in your NAMES or TOPIC commands). The IRC protocol specifies that all lines need to be termiated with \015\012. If you're running your code on windows you're in luck since that's exactly what \n generates, but on other platforms this may not be the case so it's safer to explicitely use \015\012 (or some suitable constant of course).