in reply to (tye)Re: Sending an array through a socket!
in thread Sending an array through a socket!
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
(tye)Re2: Sending an array through a socket!
by tye (Sage) on Oct 05, 2001 at 09:47 UTC | |
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: 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] |
by flipxor (Initiate) on Oct 05, 2001 at 22:22 UTC | |
$ClassSpec, $TransID_Hi, $TransID_Lo, $Rez, $AttMod ) . $Data; confuses me.... Why is there a . before $data and $data is not part of the pack? | [reply] |
by tye (Sage) on Oct 05, 2001 at 22:30 UTC | |
Because $Data doesn't need to be transformed so I can just append it to the output from pack. Also, because I didn't want to look up how to do that inside pack. (: Having now looked it up, you can use "a*" or "A*" to include an untransformed string so append " a*" to the first argument to pack and change the ") ." to ", " if you like. - tye (but my friends call me "Tye") | [reply] |
by flipxor (Initiate) on Oct 13, 2001 at 03:09 UTC | |
Or am just not thinking.... probably the latter ;). I'm still not getting it to work for me. My newbiness has definitely gotten me in a bind Maybe this is my massive bit of desperation. But I can implement what I want to in C (when creating the packet) But I still need Perl to interpret the data from a web page. Could I just possibly interface this C code with my perl to generate the packet for me? Perl will just pass the values through to my C code with the correct arguments? So that's my C. But my ugly arse PERL code looks like this:
2001-10-13 Edit by Corion : Added CODE tags | [reply] [d/l] [select] |