Receive data through TCP connection

[Oesen]

Hi

I'm receiving a string "Hello" from TCP from a C-program, where I have to display this string in a string indicator in LabVIEW. 

I have the following block diagram I found among the examples: 

The point here is that I can only read the last character "o" in the indicator when I change the "bytes to read" value to 4 bytes, but can read the characters "ello" when setting the bytes to read value to 1. How do I read the whole "Hello" string ?. 

[nathand]

You need to understand what that code is doing. That code expects to receive a 4-byte value indicating the number of bytes of data, followed by the actual data. If you send the string "Hello" without that byte count, it won't work as expected. When you set bytes to read to 1, you read the "H" which then gets type cast to an integer. Since the ASCII value of "H" is more than 4, you read the following 4 bytes. When you set bytes to read to 4, it captures the first 4 characters (H e l l), leaving only the "o" when you do the second read. To read all of "Hello" you should either send the value "5" (NOT the text "5" - these are different concepts) in 4 bytes prior to the the actual string (and set Bytes to Read to 4), or you should do only a single TCP Read for 5 bytes since that's the length of Hello.

[MrHappyAsthma]

Since you are sending a string, I would try using "CLRN" mode on TCP Read.  Then you can trigger it to read all the text until the "/r/n" characters in C.

mode indicates the behavior of the read operation. 0 Standard (default)—Waits until all bytes you specify in bytes to read arrive or until timeout ms runs out. Returns the number of bytes read so far. If fewer bytes than the number of bytes you requested arrive, returns the partial number of bytes and reports a timeout error. 1 Buffered—Waits until all bytes you specify in bytes to read arrive or until timeout ms runs out. If fewer bytes than the number you requested arrive, returns no bytes and reports a timeout error. 2 CRLF—Waits until all bytes you specify in bytes to read arrive or until the function receives a CR (carriage return) followed by a LF (linefeed) within the number of bytes you specify in bytes to read or until timeout ms runs out. The function returns the bytes up to and including the CR and LF if it finds them in the string. 3 Immediate—Waits until the function receives any bytes from those you specify in bytes to read. Waits the full timeout only if the function receives no bytes. Returns the number of bytes so far. Reports a timeout error if the function receives no bytes.

Otherwise, you need to follow the instructions per protocol;

bytes to readis the number of bytes to read. Use one of the following techniques to handle messages that might vary in size: Send messages that are preceded by a fixed size header that describes the message. For example, it might contain a command integer that identifies what kind of message follows and a length integer that identifies how much more data is in the message. Both the server and client receive messages by issuing a read function of eight bytes (assuming each is a four byte integer), converting them into the two integers, and using the length integer to determine the number of bytes to pass to a second read function for the remainder of the message. Once this second read is complete, each side loops back to the read function of the eight byte header. This technique is the most flexible, but it requires two reads to receive each message. In practice, the second read usually completes immediately if the message is written with a single write function. Make each message a fixed size. When the content of a message is smaller than the fixed size you specify, pad the message to the fixed size. This technique is marginally more efficient because only a single read is required to receive a message at the expense of sending unnecessary data sometimes. Send messages that are strictly ASCII in content, where each message is terminated by a carriage return and linefeed pair of characters. The read function has a mode input that, when passed CRLF, causes it to read until seeing a carriage return and linefeed sequence. This technique becomes more complicated when message data can possibly contain CRLF sequences, but it is quite common among many internet protocols, including POP3, FTP, and HTTP.