flatten to string for sending through TCP/IP contains CRLF characters

[mkdieric]

Hi,

I'm using a 'flatten to string' function to send some data through TCP/IP.

To minimise delays, I use the CRLF mode so that the receive function returns as soon as it receives a CRLF sequence (termination character).
I noted that every now and then only part of the data is transmitted because the flattened string itself sometimes (albeit rarely) contains CRLF characters.
I was wondering if this is correct behaviour, or if I'm missing something.I expected flatten to string to produce pure ASCII strings without special characters.

Now I first have to scan the string and replace possible CRLF characters by some known series of characters and do the opposite on the receiving side, and hope that this particular sequence never occurs.

Any comment is appreciated,

Manu

[smercurio_fc · Accepted solution]

---

mkdieric wrote: 

I expected flatten to string to produce pure ASCII strings without special characters.

---

I'm not sure why you would think this. A CR or LF is no more special than any other character. Also, the string you get out is not "ASCII", and never has been - check the documentation. The output is completely dependent on the input, and it's perfectly possible to get a CR (hex 13) followed by a LF (hex 10) if the input would produce flattened data that translates to that.

A better method, in my opinion, is to precede what you're sending with the number of bytes to expect. Then at the receiving side you read a fixed number of bytes for the numeric value that indicates how many bytes will be coming, and you read that amount. The examples that ship with LabVIEW show you this method. 

Message Edited by smercurio_fc on 10-29-2009 09:16 AM

[mkdieric]

Hi,

thanks for the feedback. I'll use the way you describe, by first sending the number of characters to expect.

Manu

[Mark_Yedinak]

---

mkdieric wrote:

Hi,

thanks for the feedback. I'll use the way you describe, by first sending the number of characters to expect.

Manu

---

Make sure you are consistent with the format for the number of butes. That is, always use an 8, 16 or 32 bit value. Which one you use is up to you and will depend on the size of your data. A 32 bit value is the most common size to use. Anyway what I am basically saying is that if you are inconsistent with what size number you use for the size you will get inconsistent results when you read the data since you will be interpretting the size incorrectly some of the time.