New Read/Write VIs for TCP and UDP connections

[Mark_Yedinak]

I would like to see new Read and Write VIs for TCP and UDP connections that worked the same way the Read From Binary File and Write To Binary File work. These file VIs are polymorphic and allow you to specify the format of the data being written or read. With only the current Read and Write VIs available for the TCP and UDP connections we must always include typecasts or other data parsing. LabVIEW obviously has the means to do this since it exists for files. Extend that capability to the newtrok connections as well.

[Mr.Mike]

I agree with the spirit of this (make LabVIEW easier!).  I don't think NI should do this unless the format of data for Read From / Write To Binary File is completely documented and released publicly, perhaps with reference implementations in a few popular langauges.  That documentation should also explain that the data stream is not the only information required for understanding what data you're looking at.

Why?  It's filled with gotchas.  The format for data for Read From / Write To Binary File is complex.  Basic types are fine: ints, strings (we use long pascal strings. i.e. 4 byte size followed by the bytes in the string), and bools.  Now, what about arrays of those types?  That's different, since ints and bools are fixed sizes while strings are variable sized.  Of course, you could choose not to include size information, which means you need to specify how many items to read or write.  So, you may need to know how many items you're expecting to read.  If you have a cluster, I don't remember what happens, but I'm pretty sure the information about what's in the cluster is never read/written, you just need to have the same cluster type on either end.

(I'm ignoring endianness because network traffic should be transmitted in network byte order, no ifs, ands, or buts.)

So, yes, it's a cool idea, but if we're talking TCP/UDP, we're also talking external applications.  And if we're talking external applications, there really needs to be documentation about what is going to be and won't be transmitted.

[Mark_Yedinak]

Mr. Mike,

I fully understand your concerns and can appreciate what you are saying. I have been living in the networking world my entire professional career. I do believe that this could be implemented in such a way that would make it easy for external applications to work with the data and be able to understand the data. I realize this wouldn't be easy but it is doable.

[tst]

Incidentally, not only is this doable, but it has already been done. These primitives (called TCP Flex R/W) have already been created in the past and have been an undocumented part of LV. I have no idea if they're still around, but since NI never officially exposed them, I'm assuming they had some problems.

Personally, as I'm sure Mark and everyone else has, I've gotten used to the flatten to string and unflatten on the other side while sending the size of the data separately method. Additionally, it's been a long time since the last time I had to send data like this, so I don't feel the need for this as much as I used to.

[Mr.Mike]

tst,

It took me a while to find those, prims, but I did.  They don't compile (at least in 2010), or I was doing something else wrong.  Thanks for pointing them out.