[Gambas-user] gb3 RC1: using structures to replace the loss of Mk$ functions

[Kevin Fishburne]

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: sales at ...1887...
phone: (770) 853-6271