> 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@codex,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. Regards, -- Benoît Minisini ------------------------------------------------------------------------------ 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
