$SIG{PIPE} = sub {close $active; exit (3)};
sub readn
{
   my ($socket, $bytes ) = @_;
   my $offset = 0;
   
   my $buf = "";
   while ($offset < $bytes)
   {
      my $nread;
      my $nleft = $bytes-$offset;
      
      $nread = sysread($socket,$buf,$nleft,$offset);
      kill 'PIPE',$$ unless (defined $nread);  ## undef is like -1 uni
+x return
      last if ($nread ==0);                    ## EOF
      
      $offset += $nread;
   }
   
   return ($buf,$offset);
}

sub writen
{
   my ($socket, $buf) = @_;
   my $bytes = length $buf;
   my $offset =0;
     
   while ($offset < $bytes)
   {
       my $nwritten;
       my $nleft = $bytes-$offset;
       
       $nwritten = syswrite($socket,$buf,$nleft,$offset);
       kill 'PIPE',$$ unless (defined $nwritten);  # undef is like -1 
+unix return
       
       $offset += $nwritten;
   }
   
   return $offset;
}
[download]

When the client sends 256 bytes, often the readn() will see 2 128 byte receptions even if both client and server are on the same machine. In practice, you will see "hunks of data" even if client sends "huge thing" or "byte at a time". A couple of "trips" through sysread is no big deal.

Note when I see undef from sysread(), I send SIGPIPE to myself! This is so "client went away" is handled consistently and "by normal method".

There is no need to read one byte at a time even if you want to read "lines". Just check for network line termination at the end of the received bytes to see if you need to continue to loop for more bytes.

Note: network line termination is: carriage return, line feed NOT \n. In Perl, if you write a string to a socket, Perl will send the right thing. But if you are receiving bytes or sending raw bytes, it is up to you to do the "right thing".

The above is not "finished code" for your specific app, but I hope it gives you a starting place. Your line oriented code that "does not hang" will be similar and about the same length.

Update:

I found a complete client/server application pair written in a)Perl and b)C for you. This is a demo forking server. The client is able to query "who" is on the server. What the client/server does is not that impressive. How it does it and the use of the normal signals is much more to the point.

Perl Server:

C Client/Server: The C code of the above is longer, much longer. Since this is a Perl forum, I am not sure that it would add value, but if requested, I will do it.

Yeah, I know the line terminators are "wrong" in my server; it's for an existing local protocol with existing clients and servers, so I can't mess with that. So "\n" is "right" for this case, though non-standard.

I see you're going down to the sysread level. That's probably the cleanest solution. I started out using line-mode reads, which was working fine until we uncovered the clients that didn't terminate their last line. Since the value proposition for this server is increasing our flexibility in deploying multiple copies of servers, bundling commands into servers dynamically, and so forth, without having to change and redeploy all the clients, that was kind of a quandry, so I've had to give up line-oriented IO. But because you're using fixed-length packets, you avoid the actual problem that trapped me.

You say in the code that the "next" if accept returns undef isn't necessary any more, but I've seen my $listen->accept() call return EINTR (perl 5.8.8, Linux 2.6.18), so it seems to be necessary still here.

I really appreciate a more sophisticated running example. I've been wondering about things like closing the handles not used after the fork, for example; you seem to think that's worth bothering with.

I would like for you to explain what this means:

until we uncovered the clients that didn't terminate their last line What?

They closed the socket before sending \r\n?

My code deals with that.

because you're using fixed-length packets, you avoid the actual problem that trapped me
No, not at all.

I thought that I explained clearly how to deal with an indeterminate length \r\n terminated packet.
What was not clear?
Obviously something was not.
It would help if you could ask the question in a different way.

Please look at: sysread. sysread() will return with a number of bytes read.
If the other side sends: "1234\r\n", just look at the end of the buffer to see if there is a line termination (last 2 bytes).
What's the problem?
I think that you can easily adapt my code to deal with your requirements.

My mind's been a bit muddled lately ;-), and I only have grasped the tip of your iceberg, but it is reminiscent of using FIONREAD. Run perldoc -q filehandle and search for the section under How can I tell whether there's a character waiting on a filehandle? It explains how to use FIONREAD. You can also look at my example of it's use in IPC3 buffer limit problem. I hope it's useful to you.

Okay, non-blocking IO gives me an error, errno == EAGAIN, when no data is available. So then I can loop and busy-wait on data becoming available? Ick! So I put in a usleep(10), and that dropped the CPU use from 100% to 0% while waiting for input, which seems like it's low enough to not bother about too much (dozens of clients, remember; if it were thousands I might have to work harder). So this works in my test code, and it seems to work in my real code as well (test cases running as I type).

The other choice is select(), but select requires sysread rather than ordinary read, meaning I'd have to do my own buffering implementation for the cases where I have to read line-oriented data. That might be the solution if I needed to support thousands of clients, though, it'd probably waste less cpu horsepower than my usleep(10) does.

This should be core perl territory, and I feel like I'm struggling quite a lot due to the environment not making it easy. Am I missing a better way? Or do I just have to do this over and over until it becomes simple and comfortable in my head?

The documentation could have saved me days of annoyance by being a bit clearer about how read() behaves.

See my code.

After the fork(), the parent closes the active socket because the parent does not talk to anybody - it only listens for new connections.

After the fork(), the child closes the passive socket because the child doesn't listen for new connections - it only talks on the active socket to the current client.

I was using $socket->close(), rather than your close $socket. They should be equivalent, I thought, but I also thought I had trouble (closed on both sides) when I did the OO version. I've put in your version, and it hasn't broken anything (and will presumably be more stable in heavy use and under adverse conditions).

close $socket provides exactly the same functionality albeit faster than $socket->close() because a Perl object method call has more run-time overhead than a subroutine call.</c>

So what does it mean when the following code:

    $! = 0;
    $res = $sock->read($data, 255);
    # $res: #chars, or 0 for EOF, or undef for error
    $err = $!;
    $iologger->debug("bufrd res " . safe($res) . ": " .
             safe($data) . " err $err");
[download]

Logs this:

2011-10-13 09:21:39,782 DEBUG kcmdproxy.child.io(30674):366 bufrd res 
+<<127>>: <<simkserver<sp>30665<sp>port<sp>2001<sp>client<sp>127.0.0.1
+<sp>command<sp>special<lf>1,8,7,2,13,1,12<lf>13,5,11,10,8,0,13<lf>5,2
+,11,4,5,10,5<lf>3,5,7,10,12,2,12<lf>>> err Resource temporarily unava
+ilable
[download]

The socket call returned 127, which should be a number of characters (and looks about right). And it also set $! (which I had carefully set to 0 before the call). There isn't threading going on, and the signal handling is at the level of setting one variable in the handler, so nothing else should be interrupting to set $!. I suppose I could localize it, just as a test, to see if this still happens, but I don't see how something else can be getting in to set it. Does the $! value mean anything in this case, or is it just garbage?

$! only has meaning if the operation failed. After a success its value could be anything.

perldoc says: If used numerically, yields the current value of the C errno variable, or in other words, if a system or library call fails, it sets this variable. This means that the value of $! is meaningful only immediately after a failure: