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

[Kevin Fishburne]

On 04/07/2011 05:05 AM, Benoît Minisini wrote:
>> On 04/05/2011 03:34 AM, Benoît Minisini wrote:
>>>> On 04/05/2011 01:39 AM, Kevin Fishburne wrote:
>>>>> Alright, I've transformed all the networking code to the suggested
>>>>> solution, and it's so close to working I can smell it. While there is
>>>>> more code now, I like it better as it's easier to read (important!).
>>>>>
>>>>> Some code:
>>>>>       Dim id As Byte
>>>>>       Dim type As Byte
>>>>>       Dim data As String
>>>>>
>>>>>       id = Read #udp As Byte
>>>>>       type = Read #udp As Byte
>>>>>       If Eof(udp) = False Then data = Read #udp, Lof(udp) - 2
>>>>>
>>>>> Using "Lof(udp) - 2" as the length seems to remove bytes from the end
>>>>> rather than the beginning. I get an unwanted byte at the beginning as
>>>>> well.
>>>>>
>>>>> Maybe this is a late April Fools joke about endianness? Other than
>>>>> that, the whole app is ready to put pixels on the screen again
>>>> After checking my code for bugs (none found, knock on wood) and doing
>>>> some experimentation, it looks like sending certain data types using the
>>>> new method works fine, but other data has an extra byte added in front
>>>> of or in-between variables. Any info about what's really happening is
>>>> appreciated.
>>>>
>>>> Again what I'm trying to do is send an ID (Byte), type (Byte), and a
>>>> sequence of arbitrary variables via UDP. When they're received, the ID
>>>> and type are read normally as Bytes into variables and the rest of the
>>>> data is read into a string and stored in an array for later processing.
>>>> The arbitrary variables stored as a string (everything after ID and
>>>> type) are later interpreted via the *@() functions and assigned to
>>>> variables. To do this I just created a different UDP_Write procedure for
>>>> each transaction type so the packets/transactions are properly
>>>> assembled. I've attached some code excerpts if anyone desires greater
>>>> specificity.
>>>>
>>>> In summary of the attachments, the failure basically goes like this:
>>>>
>>>> ' Send username and password.
>>>>
>>>>      ' Send the transaction.
>>>>      udp.Begin
>>>>
>>>>        Write #udp, id As Byte
>>>>        Write #udp, 50 As Byte
>>>>        Write #udp, credentials As String ' credentials =
>>>>
>>>> "myusername,mypassword"
>>>>
>>>>      udp.Send
>>>>
>>>> ' Read the username and password.
>>>>
>>>>      id = Read #udp As Byte
>>>>      type = Read #udp As Byte
>>>>      If Eof(udp) = False Then data = Read #udp, Lof(udp) ' Username and
>>>>
>>>> password separated elsewhere, not a problem.
>>>>
>>>> data should be "myusername,mypassword" but it actually is
>>>> "^Uanon at ...2571...,mypassword". "\x15" prepends the string, strangely. I
>>>> think this errant byte also precedes any number of datatypes that are
>>>> send separately and later read as a single string. What is this byte,
>>>> and how may I get rid of it?
>>> Not strange if you read the doc carefully. :-)
>>>
>>> When using "WRITE #Stream, AString As String", the length of the string
>>> is always written before the string contents.
>>>
>>> To just write the string contents, you must use the second syntax of
> WRITE:
>>> 	WRITE #Stream, String, Length
>> Writing strings and bytes works fine now, but singles and shorts, not so
>> much. Here's an example of what's happening:
>>
>> Server - Send ID (0), type (70) and two singles (2279, 1440) as UDP:
>>
>>     ' Define target's IP address and port.
>>     udp.TargetHost = ip
>>     udp.TargetPort = port
>>
>>     ' 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
>>
>> Client - Read ID and type into their own variables (id, type) and the
>> two singles into a string (data):
>>
>>     id = Read #udp As Byte
>>     type = Read #udp As Byte
>>     If Eof(udp) = False Then data = Read #udp, Lof(udp)
>>
>> Client - Display the value of data (double click it in the IDE):
>>
>>       E\x0Ep\x00D<?>\x00\x00
>>
>>       The "<?>" is actually one character, a question mark in a diamond.
>>
>> Client - Print the value of data in the console (?data):
>>
>>       E^Np^@D�^@^@
>>
>> Client - Print the length of data in the console (?Len[data]):
>>
>>       8
>>
>> Client - Convert data from a string back into two singles:
>>
>>       Single@(Mid$(tsdata, 1, 4))
>>           1.029069E-38
>>
>>       Single@(Mid$(tsdata, 5, 4))
>>           6.466712E-41
>>
>> Any idea why 2279 becomes 1.029069E-38 and 1440 becomes 6.466712E-41?
>> Sending a short of 1234 is read as "\x04<?>" (double click) or "-11772"
>> (Short@[data]). It looks like either the Read function is doing
>> something strange with the data when assigning it to a string, or the
>> *@() functions aren't working the way they used to. In case anyone
>> forgot, I was previously using the Mk*() functions to create a string
>> from variables and the *@() functions to convert the string back to the
>> original datatypes.
> Because sockets are big endian, not little endian as the CPU. I think you have
> to use READ to decode the messages as soon as you receive them.
>
> If you want to process them later, you can use a Variant[] to store the
> decoded data instead of a String storing the undecoded data.

I don't know what to say. The endianness should automatically be 
decoded; I thought was the whole point of removing the Mk*$() functions.

A transaction can be something like, "Okay, good job" or an entire clip 
of the world terrain in dozens of blocks. It can't just be stored in an 
array as a Variant.

What do the string values mean? Are they reversed and/or inverted bits? 
If I can flip the bits I can get back to work.

-- 
Kevin Fishburne
Eight Virtues
www: http://sales.eightvirtues.com
e-mail: sales at ...1887...
phone: (770) 853-6271