TCP Write / bytes written

[ali.mootaab]

I stablished a communication between my PC and a cRIO using TCP protocol. I use TCP Linsten.vi on the PC and TCP Open Connection.vi with PC IP address on the cRIO to stablish the connection.

I need to send some command and data from PC to cRIO. To do so, I use the TCP Write Function on the PC to send the data and command and the TCP Read Function on the cRIO to read them. It is straight forward. If I write "abc" string to the TCP connectoin I will read "abc" on the other side.

I want to know if this communication is 'guaranteed'. I mean, if I write "abc" do I definately get "abc" on the otehr side with the same order? How can I find out (on the PC side) that the "abc" is correctly delivered or not?

What does the ‘bytes written’ mean in ‘TCP Write Function’? Does it mean the number of bytes written to the PC buffer or the number of bytes received on the cRIO side? Does the error out have any indication of the data delivery?

I appreciate any help.

Thanks,

Ali

[BowenM]

The way that the TCP protocol works (simplified)

1. Sender transmits information

2. Sender waits for ACKnowledgement from receiver

3. If timeout w/o ACK, sender retransmits data.

4. If total timeout with no ACK, reports failed send.

So, the "bytes written" is the number of bytes that your LabVIEW program received the ACK for.

[crossrulz]

Part of the TCP/IP protocol is guarantees of data arrival.  At the packet level, they may show up in a different order, but the protocol includes packet numbers so the reciever can peice the data together properly.

If a connection was lost, I know you will get an error.  I have luckily not been on a congested network to see if there is a timeout error.

You might want to look into using the STM library from NI Systems Engineering (available on VIPM) or Network Streams (part of LabVIEW).  They absract some of this away from you.

[ali.mootaab]

Thank you for your quick response.

I found the following discussion, yesterday. It seems if there is a disconnection, the write block still returns the number of bytes on its input. It is weird because if there is a disconnection then the bytes written should be zero. Also, the LabVIEW help for TCP Write Function says "bytes written is the number of bytes the VI writes to the connection". It does not say the number of bytes acknowledged by the receiver.

http://forums.ni.com/t5/LabVIEW/TCP-Write-bytes-written/td-p/612884

Is there any reference that you can provide me with more specific details? I really appreciate that.

We had a list of available options for the communication protocol including STM and Network Streams. At the end we concluded to use the TCP because other non-NI devices can also be connected to this communication. Also, the reference are more available than other protocols.

Thanks,

Ali

[Ben]

While I will not try to expalin what the # bytes written means, I will confirm that TCP by definition does gauarentee delivery on the order. That should be something you could find if you look at the definition of TCP on wikipeadia and dig into the Microsoft version fo the network stack.

TCP is wicked impresive considering a large packet may be decomposed into multiple smaller packets with each packet potentially taking different routes AND the ACKs making it back to the originating machine.

Ben