LabVIEW
TCP/IP multi device connection
@Mark_Yedinak wrote:
@Baterflu wrote:
I cant use low timeout because network delay can get big.
Thank you for your response
There are two methods of handling timeouts when working with communications. One, like queues is to use an infinite timeout which simply waits for data to arrive. once there, it will read the data. This is the most efficient way since the PC will be doing nothing when there is no data available.
The other method is to use short timeouts and handle the timeout error. Using this method timeouts are to be expected. When a timeout occurs you ignore that error and do whatever other processing you might need to do. Then go back and check for data again. Repeat this process. This is useful if some processing is required that is also done by your receiving task. This is basically a polling task. It is using CPU cycles doing essentially nothing.
I generally try to avoiding polling if possible.
I couldn't have explained it better. And while it is always better to avoid polling if that is possible, you have to consider the impact. Polling with a 50 ms timeout means 20 cycles per second. Unless you have a few zillion devices that all need to be polled in parallel (in most of my even very complicated applications I don't really have more than maybe a dozen or so 
) the performance impact of such a polling is completely lost in the measurement noise when the application is fully working. And even when it is completely idle, the few microseconds of CPU performance used for such polling will at most prevent the system to fall into full hybernation sleep
@Baterflu wrote:
I dont have problem with read data from device. I have problem with sending data to device. Because devices can be disconnected i can get timeout when trying to send frame. This blocks outgoing communication for timeout. I just want to avoid situations in which trying to connect with one device blocks others.
How does indefinite timeout help with that? If the device is disconnected the underlaying socket will eventually abort and deliver an error to LabVIEW which will abort your Write too and return an error. It's not like the Write will eventually happen if the device magically returns online, since the socket that has been connected to that device has no means to automagically reconnect (except when the disconnect was not a real disconnect but a brief interruption of network connection and with brief I mean typically seconds at most, not minutes). You need to close the current socket and connect a new socket explicitly anyhow to be able to do a retry on the write.
Timeout on the TCP Write is in most situation really a no operation since the TCP Write simply copies the entire data buffer into the socket buffer and returns immediately. As far as TCP Write is concerned, the data was successfully delivered and the socket driver is expected to do its work in the background. Only if you try to write huge amounts of data with TCP Write to a single connection can this function eventually wait at all, as it will attempt to copy as much as possible into the socket buffers, which are of course not indefinitely sized, and if it can't do that in one go it will start to wait and retry to copy the remainder to the socket buffer until either the socket driver returns an error, the timeout expires or all data was successfully copied to the socket buffer. But huge here means typically something like more than 64kByte of data. So in most cases the timeout passed to the TCP Write has no real functionality as it is never really reached anyhow even if you keep it very low.
A large timeout to TCP Write but even more so to TCP Read has exactly the potential to block other operations in your application depending on your architecture. Shorter timeouts with proper timeout error handling other than just baling out because the function returned an error, is the way to avoid such blocking, not to cause it! Or creating an application where all your functions are fully asynchronous by properly using reentrant VIs, but then both long or short timeouts will not have any influence on your blocking behaviour anyhow.
