Binary Header Problem w/ Foxpro 6.0 & Winsock

[tetsuo3030]

Hello..I am having a problem retrieving data properly via Winsock in Foxpro 6.0. My client is supposed to receive an ASCII message that has 2-bytes attached to the front that is supposed to represent the length of the ASCII message in bytes.

for instance, if the incoming ASCII message is: 'abcdef'

then the message would come across as: chr(0) + chr(6) + 'abcdef'

obviously, I'm just using CHR(0) to represent the first byte(00000000) and CHR(6) to represent the second byte of the header(00000110)..

my problem is that by the time the Winsock method .DataArrival() fires, the data has been corrupted..I can try to print the data to file and all I see is blank spaces(although the length is correct). I have used Ethereal to verify that the data section of the packets I am receiving do indeed contain the correct information, so it seems that Foxpro/Winsock is unhappy with the first byte(the CHR(0)) and it seems to be corrupting the rest of the message somehow. Does anyone know how to get around this problem? I'm only receiving 1 large packet from the server application so I have to be able to pull the binary data "away" from the ASCII data somehow..

Any ideas?

 

[mspratt]

Shouldnt't tou be using CHR(48) + CHR(54)?

Regards,

Mike

 

[Mike Lewis]

Couldn't you use STRTRAN() to get rid of the binary zeroes? Something like:

NewMessage = STRTRAN(InMessage, chr(0), "")

(I suspect that Winsock is seeing the first CHR(0) as the end-of-string marker, and discarding everything after it.)

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[tetsuo3030]

CHR(48) is 00110000 and CHR(54) is 00110110..

the binary header that precedes my message is:

00000000 01000110
-------- --------
DEC=0 DEC=70

 

[tetsuo3030]

Mike(Lewis)..yes I should be able to do that(use STRTRANS)..

the problem is I can't figure out where this needs to be done. When the Winsock method .GETDATA(@lcData) returns back to .DATAARRIVAL(bytestotal), it lcData is already blank! When I run the commands through the Command window and print out what the lcData holds, it shows junk characters(looks like memory)..while the first character is always a CHR(0) and I can remove it, the string is already corrupted at this point and the ASCII can't be retrieved...(I've posted the output to a Hex editor and just see junk that doesn't match the Data portion of the packet I see in Ethereal)..

...

 

[mspratt]

I don't know where you are getting all this binary data.

When I issue ?CHR(48) + CHR(54) in the command window I get 06.

Regards,

Mike

 

[tetsuo3030]

You do understand that data comes across the wire in binary format, right? The server is sending me ASCII preceded by bytes that signify the integer value of the length of the ASCII message. So in Ethereal, I can see that the HEX of the first two bytes is 00 and 46 respectively. 00 expands to 00000000 in binary and 46 expands to 00101110. I should never have mentioned CHR(0) and CHR(46) above as they just confuse the real issue here...I just thought that it would be easier than printing out the binary.

so lets pretend the message coming back to me from the server is 'ISO'. the length of the message will be 3 so the 2-byte header will be 00000000 00000011. so after that is attached to the ASCII, the binary will look like:

00000000 00000011 01001001 01010011 01001111
0 3 'I' 'S' 'O'

int int chr chr chr

 

[mspratt]

You do understand that in ascii 00000000 = NUL and 00000011 = SOH.

Regards,

Mike

 

[tetsuo3030]

>> You do understand that in ascii 00000000 = NUL and 00000011 >> = SOH.

Matt, I do understand this. The fact that 00000000 = NUL is exactly my problem here! I'm trying to interpret the data coming across as an Integer followed by a bunch of ASCII data. Instead of seeing the first 2 bytes as a integer, Foxpro is interpreting it as a NULL and then all of the data that follows(i.e. the other header byte + the ASCII message) all show up as spaces.

My problem is that I can not seem to get Winsock to distinguish between the two types of data here. It is trying to return the entire data portion of the packet as a single string..since it is a single string, I am receiving the equivalent of:

chr(0) + chr(46) + myASCIIMessage

and the chr(0) is screwing up the data that follows...does this make sense?

 

[tetsuo3030]

well, I think I found the root of the problem..VFP 6.0 does not support byte arrays..if the Winsock.GetData() command encounters a NULL then it simply stops processing...that's the reason i get the NULL and then a bunch of junk afterwards..

 

[mspratt]

Perhaps the problem you are having is that integers have to be 16 or 32 bits. When you use CHR() you only send 8 bits.

Try the INT() function instead.

Regards,

Mike

 

[agoeddeke]

Try retrieving the data one byte at a time to see if it helps. I seem to remember a problem retrieving data that was all NULL, but getting it one byte at a time fixed it.

** Dataarrival event
FOR lnCounter = 1 TO bytestotal
		lcString = CHR(0)
		THISFORM.oleSocket.GetData(@lcString, 8, 1)
		THISFORM.r_cReceiveString = THISFORM.r_cReceiveString + lcString
ENDFOR

It's worth a try.

Andy

 

[mspratt]

I found this interesting from the command window:

? INT(0),INT(3)

Regards,

Mike

 

[tetsuo3030]

i got this fixed..i ended up taking a little bit from everyone..

my final solution involves calling GetData() from the DataArrival() event with the size of the binary header(2 bytes)...when that returns, I simply call GetData() again with the size of the ASCII message and since the first two bytes aren't present, Foxpro doesn't have a problem since no 00000000 bytes exist in the data..

thanks all!