castaway has asked for the wisdom of the Perl Monks concerning the following question:

I think I've found a bug, or at least some incorrectness, in the perldoc for the 'recv' function.

How so? Well, I'm attempting to use the Net::Time module, to grab the current time from a remote machine. This fairly simple code works fine on Linux, but not on HP: 

perl -MNet::Time=inet_time -le'print inet_time("volvo", "tcp", 10);'

[download]
('volvo' is the HP-UX machine, which means Linux can get the time from HP-UX, but HP-UX can't get it from itself..)

After digging in the code, I noticed the problem is with the following: 

 return undef
        unless $s->recv($buf, length(pack("N",0)));

[download]
Looking at the docs for 'recv', it should return the senders address, if supported by the socket protocol (I assume udp and tcp do, since both can be used for the time protocol), and an empty string otherwise, and undef on error. recv is based on the system call recvfrom. So this code should actually be checking for undef, and indeed changing this solved the problem, for the Net::Time module.

So wheres the bug? The manpage for 'recvfrom' on the HP-UX 11.0 machine says, explicitly, that the 'recvfrom' system call behaves the same way as the 'recv' system call, except that it does not return the senders address. Thus perls 'recv' does not behave according to its documentation, on HP-UX.

This was all tested with v5.6.1 perl + docs, and the latest libnet from CPAN (which contains Net::Time). I also peeked at the v5.8.0 docs for recv, which claim the same thing, and in the Net::Time module in the 5.8.0 core, which has the same bug.

Since I'm not subscribed to p5p (and don't aspire to be), where else should I report this, apart from the RT for libnet?

And would anyone else like to confirm it?

C. (breaking things today..)

Replies are listed 'Best First'.
Re: perldoc recv, Net::Time and HP-UX
by KPeter0314 (Deacon) on Jun 19, 2003 at 19:19 UTC
    Confirming what you are seeing, I tried this on a couple of our systems. Solaris, RedHat Linux, and HPUX. Some with 5.6 and some 5.8.

    I must be seeing something different than you. I couldn't get the 'tcp' inet_time to work, but 'udp' works like a charm across the board. I checked and the tcp time service just to be sure I wasn't going crazy and it was running on all these servers.

    I was just using your one-liner. Is there something else that needs to be done to get the tcp results?

    Slightly modified to see if there really was ouput:

    # perl -MNet::Time=inet_time -le 'print "1: ", inet_time("localhost", 
+"udp", 10 ), ":\n";'
1: 1056049512:
# perl -MNet::Time=inet_time -le 'print "1: ", inet_time("localhost", 
+"tcp", 10 ), ":\n";'
1: :

    [download]
    This works the same for any of the above type hosts instead of "localhost".

    As far as reporting this goes, have you tried the author Graham Barr?

    -Kurt

[reply]
[d/l]
      I didnt test udp much, as its not running everywhere here, but now I see you are right.. Seems I should have read HP-UXs docs more closely:

      recvfrom() operates in the same manner as recv() except that it is abl
+e to return the address of the socket from which the message was sent
+.  For connected datagram sockets, recvfrom() simply returns the same
+ address as getpeername() (see getpeername(2)).  For stream sockets, 
+recvfrom() retrieves data in the same manner as recv(), but does not 
+return the socket address of the sender.

      [download]
      So it returns the address for udp, but not for tcp.
      You did try it *on* the OSes mentioned, and not *to* them, right? (It should work fine from Linux, at least, it does here.)

      Anyfish, I see someone already reported on libnet that the recv line should be changed to check for 'defined', about 8 months ago, and it hasn't been changed yet.. (OTOH the explanation why possibly wasn't very clear) So I'll probably write to him and ask. (Seeing as there was a new libnet recently, just not fixing that bug..)

      After looking at various docs I'm now all confused as to whats incorrect. perldoc recv says: 

      Returns the address of the sender if SOCKET's protocol supports this; 
+returns an empty string otherwise.

      [download]
      What does it mean with "SOCKET's protocol"? I assumed that meant tcp or udp etc. In which case different behavior on hp and on linux is a bug. If it just means 'supported at all', then it's just a misleading doc.. Further, the recv/recvfrom manpage on Linux says they all return the length of the data received, bah, I'm confused ,)

      C.

[reply]
[d/l]
[select]
        My testing was matrixed *from* each of the four selected systems *to* each of the other systems and another try on a loopback to itself for a total of 16 tests.

        I'm probably missing something for the tcp side. It should work, but I haven't put a lot of time into it.

        You can /msg me if you want more details. Looking at your node we are a few hours off so replies will probably be slow.

        -Kurt

[reply]

Back to Seekers of Perl Wisdom