Re^3: Problem Transmitting Data via TCP/IP

But what do you mean "wrongly coded"? How should htonl() be defined?

Your htonl:

sub htonl {
  my $input = shift;
  my $output = unpack( 'N*', pack( 'L*', $input ) );
  return $output;
}
[download]

First, takes the number and "packs it" (converts it to binary) as a signed long:
Which means that the return from that first pack is 4 bytes and encoded in whatever byte-order (endianess) your current platform uses:
```
$packed = pack 'l', 17;;

print length $packed;;
4

print ord( substr $packed, $_, 1 ) for 0 .. 3;;
17
0
0
0
[download]
```
On my intel system, that means little-endian (the low byte comes first).
But then, you unpack (convert binary to ascii), those 4 bytes, treating them a big-endian long ('N'), resulting in:
```
$unpacked = unpack 'N', $packed;;

print length( $unpacked );;
9

print ord( substr $unpacked, $_, 1 ) for 0 .. 9;;
50
56
53
50
49
50
54
55
50
0
[download]
```
Resulting in a 9-byte ascii encode string containing the number: 285212672; which is meaningless.
htonl() could be correctly coded as sub htonl{ pack 'l>', $_[0] }; if you see the need for wrapping a built-in function in a silly named wrapper :)

Similarly, you will need to fix your ntohl(); something like this: sub ntohl{ unpack 'l>', $_[0] } would suffice.

That may fix the second part of your problem.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Comment on Re^3: Problem Transmitting Data via TCP/IP Select or Download Code

Replies are listed 'Best First'.
Re^4: Problem Transmitting Data via TCP/IP by scorpio17 (Canon) on Aug 09, 2012 at 20:12 UTC
Thanks again. I've never taken the time to learn how pack and unpack work as well as I should, and it looks like that mistake has finally caught up with me. For what it's worth - the original C++ code (which I didn't write) used the functions htonl() and ntohl(). I was not familiar with those, but could tell that it had something to do with encoding/decoding data, so I googled for a perl implementation, and found one in the Net::Inet module on CPAN. It's written to take an array of inputs, but I knew that in my case I'd only be sending in a single argument. As it turns out, my code did have another error: recv() returns undef if there's an error, so I had to change this: `# this is broken !!! $socket->recv($data, $reponse_length) or die "Couldn't read data from +server: $!";` [download] into this: `unless (defined $socket->recv($data, $reponse_length)) { die "Couldn't read data from server: $!"; }` [download] But everything seems to be working now -thank you!!	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: Problem Transmitting Data via TCP/IP
by scorpio17 (Canon) on Aug 09, 2012 at 20:12 UTC

Thanks again. I've never taken the time to learn how pack and unpack work as well as I should, and it looks like that mistake has finally caught up with me.

For what it's worth - the original C++ code (which I didn't write) used the functions htonl() and ntohl(). I was not familiar with those, but could tell that it had something to do with encoding/decoding data, so I googled for a perl implementation, and found one in the Net::Inet module on CPAN. It's written to take an array of inputs, but I knew that in my case I'd only be sending in a single argument.

As it turns out, my code did have another error: recv() returns undef if there's an error, so I had to change this:

# this is broken !!!
$socket->recv($data, $reponse_length) or die "Couldn't read data from 
+server: $!";
[download]

into this:

unless (defined $socket->recv($data, $reponse_length)) {
  die "Couldn't read data from server: $!";
}
[download]

But everything seems to be working now -thank you!!

[reply]
[d/l]
[select]