thanks for all the inputs. my client and server are actually running on different machine.

from the input given by you all, i figured that my problem is because sysread uses partial read. thus when i send a big file size, it will partial read it. thus on my client side i have to buffer it myself so as to append the partial data together to form back the single file.

thus i make sure of select with timeout to help me in this. below is my working code, hope it will helps anyone who encounter this problem. once again, thanks for the help!

#sysread uses partial read, so a stream of file might be break down in
+to 2-3 chunks
#thus use select to establish a timeout, if there is an interval of 1 
+sec or more where no data
#coming in, then it is sate to say there will be a new data stream, as
+ my data is coming in interval of fixed n secs.

while(1){        
  $len = 0;
  do{ 
    $offset = 0;
    if(defined $buffer){
    $offset = length($buffer);
  }
  $temp = sysread($sock, $buffer, 500000000, $offset);
  $len += $temp;    #append data together if they come in back to back
} while ($select -> can_read(1));
#if > 1 sec without any data coming in, quit
        
createFile(<filename>, $buffer, $len, 0);

#processFile();
[download]

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]

(assuming $select is set up for the $sock only.)

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!