Re^3: Parsing protocol data: unpack and bytes

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."

Comment on Re^3: Parsing protocol data: unpack and bytes

Replies are listed 'Best First'.
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
It turned out that this is not the case. The 'name' and 'clan' fields are max 32 chars, not fixed at 32 chars. Then your struct definition is wrong. If the strings are variable length, then use 'Z': `print for unpack 'n N Z C Z* C', "\x01\x01\x04\x03\x02\x01The first string\0\xffThe second string\0 +\xff";; 257 67305985 The first string 255 The second string 255` [download] That's why I structured the code a bit more than I usually tend to in perl... I'm not suggesting you stop structuring your code, just structure is differently. Java streams are just one possible abstraction of the problem. I would suggest a different abstraction that uses the power of unpack format strings. Have a different class for each packet and pass the buffer into the constructor and have it remove its stuff from that buffer. package This::Packet; sub new { my( $class, $bufRef ) = @_; my( $ping, $rate, $name, $ctpos, $clantag, $isbot ) = unpack 'n N Z* C Z* C', $$bufRef; my $nPacket = 2 + 4 + length( $name )+ 1 + 1 ## string + null + ctpos + length( $clantag ) + 1 + 1; ## string + null + IsBot # ... validate substr( $$bufRef, 0, $nPacket, '' ); ## remove this packet from th +e buffer return bless { ping => $ping, rate => $rate, name => $name, cpos => $ctpos, clantag => $clantag, isBot => $isBot, }, $class; } ## accessors go here [download] This way moves all the packets specific information inside a class that deals with that packet. Each class removes it's data from the buffer and the higher level only has to decide which packet to deal with next. 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] [d/l] [select]