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

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.

Replies are listed 'Best First'.
Re^10: IO::Socket Listen
by Eliya (Vicar) on Dec 08, 2011 at 08:53 UTC
    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]

        Eliya and Marshall , thanks for helping.

        I used wireshark to see the response time of google and it took 3ms to answer me , when i execute my script it returns me the value right away (just like google) but it keeps alive the connection even if the information has been received , I have no idea what is happening ...

        I read some stuff about Net::Pcaps , i can try to capture the package but i don't know if it'll work ... Any sugestion ?

        Thanks a lot

[reply]

In Section Seekers of Perl Wisdom