Your code can be better written as

while(1){
   my $buffer = '';
   my $bytes_read;
   do { 
      $bytes_read = sysread($sock, $buffer, 64*1024, length($buffer));
   } while ($bytes_read && $select->can_read(1));
        
   createFile(<filename>, $buffer, length($buffer), 0);
   processFile();
}
[download]

That whole timeout thing is going to backfire on you. You need to send the length of the file before actually sending the file so you know when to stop reading.

If only it were that straightforward...

The sysread will block indefinitely if the far end simply stops talking. This is not a common case, but can be achieved if the far end falls of the network for some reason (or spontaneously combusts). It is just possible for this to happen between the connection being established and the read loop being entered -- so you are best off with the $select->can_read at the head of the loop.

The $select->can_read will return in the event of an error, and the sysread will detect the error and return undef, and $! contains the error. The only soft errors I know of are: (a) EAGAIN, but that should only occur if the socket is non-blocking -- and should not occur after a can_read; and (b) EINTR. which can happen if you have signals (eg SIGALRM) going off -- but generally those will hit the $select->can_read, causing an early time-out.

So the code should distinguish: (a) time-out, (b) data read, (c) eof, (d) soft error (if any) and (e) hard error. I would do something along these lines:

  my $buffer = '' ;
  my $rc ;
  while (1) {
    if ($select->can_read(1)) {
      $rc = sysread($sock, $buffer, 64*1024, length($buffer));
      next if $rc ;
      # If any chance of a soft error... eg:
      # if (!defined($rc)) {
      #   next if $! == EAGAIN ;  # Not really expected, even with non
+-blocking
      #   next if $! == EINTR ;   # Signals !
      # } ;
    }
    else {
      # If signals floating around, can reach here if a signal goes of
+f...
      $rc = -1 ;
      last ;
    } ;
  } ;
 
  # Now: $rc == 0 => no error, == -1 => timed out, == undef => error
[download]

NB: only if you use non-blocking IO do you need to worry about EAGAIN, and then only on the basis of paranoia. You only need to worry about EINTR if you have signals going off. What I haven't covered is how to distinguish real time-outs from early exit from $select->can_read caused by signals. Just before each $select->can_read you can my $time_out = time() + 1 (or whatever the time-out is) and test for $time_out < time() -- I suggest Time::HiRes for fewer surprises here. Alternatively, you could $! = 0 just before the $select->can_read and test for $! == EINTR.

In any event, brother ikegami is correct, it would be a good idea to have some way of telling that what you receive is complete. When sysread returns 0 it means there is no more data and the connection has been closed -- this in no way guarantees that everything was sent before the connection was closed... something else may have happened to cause that !

Hi Thanks for the feedback. The reason why I have to use this is because:

first I don't know what is the length of data coming. It is of variable size

second, the client is having a persistent connection to the server, which means data keeps on coming in in interval and it is of binary format. As far as I know, sysread will block if no data is coming. Thus, there is no way I could receive 0 to indicate end of file.

I understand that the timeout will backfire due to variable circumstance of network connection . Is there a reliable way which I can defintely receive the data as a whole with the condition I'm having above

Thanks!

If you are confident that the network and the client are reliable, then the problem is more straightforward.

When the client opens a connection, sends as all the data it's going to send in short order, and then closes the connection, the server will hear the close and will know that is the end of the data. sysread will return zero, indicating "eof" -- it will not block if everything has been read and the far end has closed their end of the connection. You don't need the timeout (whose purpose would be to detect some failure such that packets stop arriving).

If things really are this simple, it would be easier to use a single read (assuming you know that the maximum amount data to be received) which will return once it has read everything sent and the far end has closed.