On 04/07/2011 12:20 PM, Benoît Minisini wrote:
>
> When you write the data to the socket, all data are converted from the CPU
> endianness (little endian for Intel/AMD) to the network endianness (big endian
> by definition).
>
> When you read the data from the socket, the data must be converted back from
> big endian to little endian, and it is done automatically by READ.
>
> But if you read everything inside a string, that is not done, because string
> are bytes, and so do not have endianness.
>
> Do you have an example of code that takes the socket data from a big message
> like you described and decode it?
>
> We will find a solution!
Ahh, I understand a little better. I don't know much about endianness,
so please excuse my ignorance here. When reading socket data into a
string how is the data affected exactly? I can think of a few possibilities:
1) The byte order of the entire string is reversed ("abcd" becomes "dcba")
2) The bit order of the entire string is reversed (00001111 becomes
11110000)
3) The byte order of the values is reversed (0000 1111, 1010 1100
becomes 1111 0000, 1100 1010)
4) The bit order of the values is reversed(0000 1111, 1010 1100 becomes
1111 0000, 0011 0101)
There are probably different solutions depending on how the data is
stored when assigned to a string. If the entire string is reversed then
things are a little more complex because the values are no longer in
sequence.
Assuming the sequence of values in the string hasn't changed, but just
the bit or byte order of each individual value, one possible solution
would be to have a function that reverses the bit/byte order of a
variable. Something like:
singlevalue = Reverse(Single@(Mid$(stringvalue, 1, 4)))
Another solution would be to add endianness control to the *@()
functions, like:
singlevalue = Single@(Mid$(stringvalue, 1, 4), True)
where the optional boolean argument would indicate if the endianness
should be changed.
I'd post the code for the larger string data interpretations but it
involves at least four modules and a ton of procedures. The server reads
five layers of 32x32 values from data files, adding each value to a
string. It repeats this nine times to form a 3x3 grid of 32x32 values
(96x96 values with five layers). The first layer's values are shorts and
the other four layers' values are bytes. The string (54 KB) is sent to
the client, who then reassembles the data assigning the values to
landscape arrays.
The simplest example would just be sending two singles and reassembling
them:
' Send the transaction.
udp.Begin
Write #udp, id As Byte
Write #udp, 70 As Byte
Write #udp, worldx As Single
Write #udp, worldy As Single
udp.Send
' Receive the transaction.
id = Read #udp As Byte
type = Read #udp As Byte
If Eof(udp) = False Then data = Read #udp, Lof(udp)
' Process the transaction
worldx = Single@(Mid$(data, 1, 4))
worldy = Single@(Mid$(data, 5, 4))
--
Kevin Fishburne
Eight Virtues
www: http://sales.eightvirtues.com
e-mail: sa...@eightvirtues.com
phone: (770) 853-6271
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
