Take a look at the Storable module
It will allow you to serialize any data structure and
de-serialize it at the other end.
You can download the module here
| [reply] |
A network packet is a string of bytes and so to put something into a packet, you first have to turn it into a string of bytes. There are lots of ways to do that, but you want to do it in a way where the other side can unambiguously turn the string of bytes that it receives back into something resembling the original data structure.
This is called marshaling.
You second example implies that the elements of your arrays are all strings of length 8 composed of "0"s and "1"s. Is this really true?
If instead of that you had an array of numbers, then you could use:
send( SOCKET, pack("C*",@array), 0, $paddr )
to send those elements over the socket and then use
@array= unpack( "C*", $packet );
on the other side to pull the elements back out.
However, you say "all of this data I need to send in binary (not ascii)". But there are lots of quite different meanings to the term "binary":
- The (text) representation of a number using base 2
- A string of bytes that contains bytes that aren't "just plain text"
- The compact native format for data that the computer uses
- A type of tree where each node can have two children
- A method for searching a sorted list by cutting the candidates in half at each step
Since we are dealing with data over a socket and because you mention "ASCII" (which is often used to mean "just plain text"), I'd think you'd mean (2) or (3). But your second example implies that you have data that is already been converted to (1). If someone told me to use "binary and not ASCII" for sending some numbers over a socket, I'd assume they meant (3) [which also implies (2)]. But I don't understand why you'd have those number in format (1) beforehand.
But if that is really what you have, then there are lots of ways to build your packet. Here are two examples:
$packet= pack "b*", join "", @array;
$packet= join "", map { pack "b8", $_ } @array;
But I'd really prefer to have more information to convince me that this is really what you should be doing. (:
-
tye
(but my friends call me "Tye") | [reply]
[d/l]
[select] |
I guess I was a bit vague. Thanks for the help, I learned a lot from your example
What I want to do is interpret a bunch of values from a web
page
put these values in an array and convert them into a home grown
packet
and send this through a socket. And I want them to be a string of 1s and 0s.
What I'm having a hard time with Perl (being a newbie) is
that I'm used to declaring unsigned 8 bit ints, 16 bit ints, etc.
The format I want to send as a packet are as so:
B: An 8 bit signed integer
Mgmt: 8 bit signed integer
ClassV: 8 bit signed integer
R: this is one bit long
Method: this is 7 bits long (int)
Status: 16 bits signed integer
ClassSpec: 16 signed int
TransID: 64 bit signed int
Rez: 16 bits signed int
AttMod: 32 bit signed int
and the Data: is 1856 bits long, can be anything.
So if I did a tcp dump, the way I want the packets to look like are:
0x06 0x01 0x07 0x00
0x00 0x00 0x00 0x00
0x00 0x00 0x10 0x00
0x61 0x1e 0x00 0x00
0x02 0x00 0x00 0x00
I've used the pack functions, but what I'm having difficulty is
with the one bit long R value and the 7 bit long Meth int.
and I have to throw it out in 1s and 0s.
Thanks....
| [reply] |
Ah, that makes more sense. But first, let's address one point where I think you are still confused:
And I want them to be a string of 1s and 0s.
Well, we are talking computers here so everything can be thought of as a sequence of 1s and 0s. But that is something completely different from a string of "1"s and "0"s, which is what you were previously creating.
The string "110001" is (on computers using ASCII) a string of bytes having values 49, 49, 48, 48, 48, and 49, in that order. Which you could also think of as the sequence of bits 00110001 00110001 00110000 00110000 00110000 00110001. See my point?
BTW, you could also think of that as the sequence of bits 10001100 10001100 00001100 00001100 00001100 10001100. You see, the order of bits within a byte is a matter of convention and not everyone uses the same convention. Luckilly, this doesn't matter because the only things that talk to each other 1 bit at a time are designed by people who are very careful to have both sides agree on the convention. So this "problem" turns out to hardly ever be a problem for software guys.
See, the byte has become the (well, nearly) universal unit of data exchange. So don't worry about the bits. Worry about the bytes.
This also means that if you want to send a 16-bit integer, you have two choices of convention: big endian and little endian. Unfortunately, this problem you do have to worry about.
One convention is that "network" data should use big-endian values. So you might want to go with that and stop worrying about it (unless you have to talk to someone who might not have gone with that, *sigh*).
Anyway, on to the answer... Your packet is very easy to construct:
$packet= pack( "c c c C n n NN n N",
$B, $Mgmt, $ClassV, ($R<<7)|$Method, $Status,
$ClassSpec, $TransID_Hi, $TransID_Lo, $Rez, $AttMod )
. $Data;
Getting the data out on the other end is a bit more complex because unpack doesn't signed versions of "n" and "N" (we don't care when using pack since it "just deals").
Anyway, the part you were having problems with is best solved by not dealing with "1"s and "0"s but with 1s and 0s. That is, shift bits around rather than convert numbers to strings.
Sorry, I'm out of time. I hope that explanation helped some. (:
-
tye
(but my friends call me "Tye") | [reply]
[d/l] |
Right off the top, there is a syntax error where you are putting a semicolon between your send statement and your error checking...
higle | [reply]
[d/l] |