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.
--
Kevin Fishburne
Eight Virtues
www: http://sales.eightvirtues.com
e-mail: sales at ...1887...
phone: (770) 853-6271