in reply to Re^7: IO::Socket Listen
in thread IO::Socket Listen

Eliya , your code provide some improvements in the performance it dont take 5 minutes anymore it takes between 30sec and 2minutes , is there anyway to make this faster? Thanks!

Here is my code now

my $socket = new IO::Socket::INET (
                                  PeerAddr => '192.168.11.244',
                                  PeerPort => '6008',
                                  Proto => 'tcp',
                                 );
die "Couldn't connect: $!\n" unless $socket;

$data = pack("CccccccCcCC",02,65,63,80,81,76,86,03,100,13,10);

if ( $socket )
{
    print $socket $data ;

    my $len = 131;
    my $resp = '';
    while ( sysread $socket, $_, $len ) {
    $resp .= $_;
    last if length($resp) == $len;
    }
    print "$resp\n";
}
close($socket);

[download]

Replies are listed 'Best First'.
Re^9: IO::Socket Listen
by Marshall (Canon) on Dec 08, 2011 at 06:55 UTC
    Try the unbuffered read() function instead of sysread(). Do not mix buffered and unbuffered reads! That will cause big trouble!

    You should be able with wireshark to tell if the problem is in the receive buffering or in the transmit delay from the other end. I am suspecting however that there is some delay while processing these very short packets. Although the time frame seems to be incredibly long! Can you provide more timing info from wireshark? What happened when you did: $socket->flush(); after the write (in Perl lingo the "print"?

    Update: I was confused.. corrected and also another suggestion posted.

[reply]
      Try the unbuffered read() function instead of sysread()

      You've got it the wrong way round.  Perl's read function is buffered, while sysread is unbuffered.   sysread is implemented via tha low-level system (OS) call read(2) (man 2 read), which is why it's called sysread.  It's this read(2) that the documentation of sysread is talking about.

      That said, flushing the socket after the print is certainly a good idea, though.

[reply]
[d/l]
[select]
        Ok, I stand corrected! The terminology is a bit different in C.

        I have another suggestion: Before doing this communication with the device, send a ping to google or somewhere that will answer right away. This will give a time reference in the wireshark trace. Then execute the code that transmits to this device. That should yield a delta time to send the actual packet over the network (measure from ping response time to the next packet to this gizmo going out). Then using wireshark see how long it takes for that thing to respond.

        First step is make sure that you are sending a timely packet. try the flush.

        Update: From the OP's description, I'm not sure where the delay is happening. And it sounds like the I/F spec to the device is not well specified. So for me, the first step is to verify that when the Perl code executes, that a packet gets sent right away to that device. Make sense? If that other device is "holding the ball" then I think we'll have more suggestions about how to "get it to do its thing" - probably involving some hacking and experimentation. I don't understand this 30 second delay stuff.

[reply]

In Section Seekers of Perl Wisdom