AsyncStreams question

[jscoulter]

Hi All.
I am communicating with a device via TCP that requires plain text for its commands.
I am able to successfully connect to the device and then pass a login command (plain text) using:

- FYI OutputStream1 = Socket1.OutputStream
DIM sCommand as string
sCommand = "MY COMMAND" & CHR(13) & CHAR(10)
oTextWriter.Initialize(OutputStream1)
oTextWriter.Write(sCommand)
oTextWriter.Flush

however if I do:
Dim buffer() As Byte
buffer = sCommand.GetBytes("UTF8")
AStreams.Write(buffer)

It wont connect. I cant tell whats been received by the device I am connecting too.
I am suspecting the "UTF8" encoding might be causing an issue, so if it is, how can use the AsyncStreams to send plain text?

Jeremy

 

[agraham]

Assuming the same command in sCommand it won't be the UTF8 encoding which should give the same values as plain ASCII, you can check by looking at the length and contents of buffer.

Are you using AsyncStreams.InitializePrefix to initialise your AStreams object? This prefixes each message with a length indicator which might be what is causing your problem.

 

[jscoulter]

you are right, it may well be a length issue.

The reason I am not using AsyncStreams.InitializePrefix is that it throws an error saying that the application has stopped unexpectedly.
I am using the emulator so not sure if this happens on a real device or not, but figure if the emulator gets an error so will the phone.

I am not exactly sure where the above error is being generated either. If I check AStreams.IsInitialized after its been called its true an it has not yet received any data, so I had t go back t using the normal AStreams.Initialize.

Jeremy

 

[agraham]

The reason I am not using AsyncStreams.InitializePrefix is that it throws an error saying that the application has stopped unexpectedly.

It will as the other end is not prefixing the length to any reply messages so in Prefix mode AsyncStreams will get confused.

so I had t go back t using the normal AStreams.Initialize.

Are you saying that in non-prefix mode it still doesn't work?

 

[jscoulter]

no the "normal" AStreams.Initialize works fine.
I was just drawn to the non-blocking aspect on the AsyncStreams.

So am I stuck with how I am doing it now since the other end is not supporting the prefix mode?

Jeremy

 

[agraham]

Why "stuck"? If it works and you are getting the non-blocking behaviour then isn't all well? Theoretically you might receive part messages and have to reassemble them but in practice, as long as the messages are less than about 1Kbyte then they will fit in a single packet and you will get them complete.

 

[jscoulter]

yes you may be right.
I will keep on fiddling. Its just a semi practical project for me to look at the networking stuff all said and done.

Jeremy

 

[jscoulter]

Got it sorted now...not the Prefic mode, just normal mode.
One small issue was the emulator !! it was taking 6-8 seconds to return a response when it connected. I uploaded the app. to my phone and it was instant as it should be....then I reloaded the Emulator and it was fine !:BangHead:

ONe thing I have found, as you may have noticed in my code, I am doing CHR(13)&CHR(10) to signal the EOL as per the requirements of the API for this device, BUT if you use the constant CRLF it doesnt actually work. If I replact it with CHAR 13/10 its fine. Might be a small bug there.

Jeremy

 

[agraham]

CRLF it doesnt actually work. If I replact it with CHAR 13/10 its fine. Might be a small bug there.

It's not a bug. In Unix/Linux newline is a single Linefeed character. In Windows it is a Carriage return/Linefeed pair. So in Basic4Android the CRLF keyword returns just a LF and in Basic4ppc it returns CR and LF.