LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

It "works", but I don't know why- Question regarding the Immediate mode on a TCP Read

Solved!
Go to solution
Highlighted

p27_0-1605812560541.png

This is the tcp read I'm asking about.  It seems to be working just dandy (ill elaborate) but I'm nervous I may just be getting lucky and would like to understand where it may go wrong.

 

I've read the help on the mode here:

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.

 

What does "any bytes" mean?  The vi seems to release as soon as a small message (containing <10bytes) comes in, but truncates data greater than the byte count...

 

Is this safe to use with a massive byte count wired in for an application where I have a set of cmds that are between5 and 16 bytes or so, then larger data exchanges upwards of a MB?  It seems to work fine, I havent encountered any errors yet running in a loop...

 

TIA

0 Kudos
Message 1 of 4
(212 Views)

Well, unlike some data, such as reading from a serial port, TCP data comes in as packets so it gets there all at once instead of trickling in byte-by-byte.  Additionally, if TCP packets come in out of order, then the TCP stack puts them back in the correct order before passing it to LabVIEW.  Pretty sure "immediate" just means "as soon as LabVIEW gets a chunk delivered from the TCP stack".  

Message 2 of 4
(200 Views)
Highlighted
Solution
Accepted by p27

@Kyle97330 wrote:

Well, unlike some data, such as reading from a serial port, TCP data comes in as packets so it gets there all at once instead of trickling in byte-by-byte.  Additionally, if TCP packets come in out of order, then the TCP stack puts them back in the correct order before passing it to LabVIEW.  Pretty sure "immediate" just means "as soon as LabVIEW gets a chunk delivered from the TCP stack".  


Yep. Basically immediate returns:

 

1) when there are any bytes available (it could be one single byte or more but since TCP/IP works with packets it basically means as soon as a packet has arrived. If the sender writes a message byte for byte seperately it could indeed mean a single byte).

2) when there was an error (such as connection closed by peer, etc)

3) when the timeout occurres

 

Generally if the sender sends one big package that is smaller than the MTU (Maximum Transmission Unit) size, then you will receive the entire packet in the immediate mode. Problem with the MTU is that it is not constant. Ethernet typically has 1500 bytes (which for local networks can be sometimes extended to 8000 bytes with the jumbo frame mode), but your modem with which you connect to the big internet may use different, smaller packet sizes, depending on your modem technology and transmission technology along the way.

 

Basically, Immediate mode is not meant for reliable data receiving without some other means, but rather to monitor the network for any incoming data if you have no good idea what you expect. If you talk with a known remote side you normally either use the Buffered mode or the CRLF mode. Immediate mode puts you kind of at the mercy of how your sender puts the data on the wire.

 

For instance lets assume the sender wants to send an array of data to you. You could prepend the size of the flattened array data and send it all in one go. Or you could first send 4 bytes containing the size and then the actual flattened data. The proper way to receive that would be to receive 4 bytes in Buffered Mode (you don't have anything useful on partial data here at all so Standard Mode is not helpful), decode the 4 bytes into the size and then read that many bytes in (preferabley Buffered mode instead of Standard Mode too) and Unflatten them back.

 

This is how the data is meant to be decoded and so it is most useful to do that.

 

Immediate mode has only limited use. Usually you would use that to wait for any data to arrive and then switch from there to another method to decode the full data frame. Or if you receive a command line stream such as from a remote shell. Here the user may type in data pretty slowly an not necessarily in a very strict format, so it can be useful to receive the data as he types and give feedback somehow.

Rolf Kalbermatter
Averna BV
Message 3 of 4
(137 Views)
Highlighted

Thanks for the explanation!

 

So in my particular application I've currently got my TCP servers and clients using the Immediate mode because I want to be able to mimic a SCPI like messaging between these processes I'm writing. 

 

There are simple commands sent like "start", "stop", and "do this", "do that" etc...  but I also have a bunch of data I want them to be able to send to any client that wants them - so for that I implemented prepending of byte count in ascii similar to how I've seen Keysight do it. 

 

(I also have jumbo frames enabled with a value greater than the maximum amount of data I may need to send)

 

I currently seem to be having some issues with timeouts and dropped responses but I suspect there's a higher level issue than the TCP stuff... time will tell, I've got a lot going on between multiple processes and need to do lots more debug and cleanup before proceeding.

 

Thanks again for the explanation - much appreciated!

 

 

0 Kudos
Message 4 of 4
(86 Views)