Re: Parsing protocol data: unpack and bytes

You're making that much too complicated. To unpack the structure listed, you only need do something like:

my( $ping, $rate, $name, $tagP, $tag, $isBot ) 
    = unpack 'S N Z32 A1 Z32 A1', $buffer;
[download]

You might need to vary that somewhat depending upon the sending system. For example you might need V instead of N if the sending system is little-endian. Or you might need to include some padding.

But work with Perl's facilities (eg.unpack), rather than fighting them as your code above is doing, and life gets much easier, clearer and quicker.

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re: Parsing protocol data: unpack and bytes Download Code

Replies are listed 'Best First'.
Re^2: Parsing protocol data: unpack and bytes by dichtfux (Sexton) on Dec 10, 2007 at 17:56 UTC
Thanks! I did't mean to fight unpack, I just wanted a wrapper class to be able to read from a buffer like this: `my $name = $self->package_reader->read_string(); my $rate = $self->package_reader->read_long(); ...` [download] Another question: with your method, I need to adapt the index of the buffer manually. How do I know how many characters 'unpack' read from the buffer? Do I have to calculate it myself? Like: `my $length_read = $Config{shortsize} + $Config{longsize} + ...; my( $ping, $rate, $name, $ctpos, $clantag, $isbot ) = unpack('S V Z32 +A1 Z32 A1', substr($self->package_reader->buffer(), $self->package_re +ader->index(), $length_read)); $self->package_reader->index($self->package_reader->index() + $length_ +read);` [download] ?	[reply] [d/l] [select]
Re^3: Parsing protocol data: unpack and bytes by ikegami (Patriarch) on Dec 10, 2007 at 18:18 UTC
`$Config{shortsize}` and `$Config{longsize}` are useless. Those are the sizes of those types your machine/compiler uses. You need the values from the remote machine, which you'll need to hardcode. Similarly, I disagree with BrowserUK's use of `s`. You need to use the remote machine's byte order, so you need to use `n` or `v`. (Then you'll have to convert it from unsigned to signed, but that's easy: `$ping = unpack('s', pack('S', $ping));`.)	[reply] [d/l] [select]
Re^3: Parsing protocol data: unpack and bytes by BrowserUk (Patriarch) on Dec 10, 2007 at 19:23 UTC
I just wanted a wrapper class to be able to read from a buffer like this: But that is exactly what I mean by "fighting unpack". The buffer has a fixed length--2 + 4 + 32 + 1 + 32 + 1 = 72--so deal with it that way. Your 'wrapper class' is unnecessary and overkill. Stop trying to write Java in Perl and just use Perl. That's just my opinion. You are, of course, perfectly within your rights to completely ignore it. 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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^4: Parsing protocol data: unpack and bytes by dichtfux (Sexton) on Dec 10, 2007 at 20:46 UTC
You are, of course, perfectly within your rights to completely ignore it. No, I don't mean to ignore it, I just gave it a try. But it turned out that it's more difficult and it most likely won't work like that (see below). The buffer has a fixed length--2 + 4 + 32 + 1 + 32 + 1 = 72--so deal with it that way. It turned out that this is not the case. The 'name' and 'clan' fields are max 32 chars, not fixed at 32 chars. :( When I read constant lengths from it, it only works if all clients use the maximum length for both 'name' and 'clan'. Funny that you mention Java, btw. You're right: I had to write lots of Java for university recently and the code I may be influenced by that. ;) On the other hand, this is not just a short script of 50 lines, it's supposed to become a (command line) multi-game server browser. So there's quite a few different buffers I'll have to handle. That's why I structured the code a bit more than I usually tend to in perl...	[reply]
Re^5: Parsing protocol data: unpack and bytes by BrowserUk (Patriarch) on Dec 10, 2007 at 23:30 UTC
Re^3: Parsing protocol data: unpack and bytes (streaming) by tye (Sage) on Dec 10, 2007 at 23:54 UTC
Yes, I've long wanted "stream" semantics for pack/unpack. If they implemented a "give me the resulting offset" option, then such could be well implemented in a module. - tye	[reply]