LabVIEW
How LabVIEW Stores Variant Data in Memory ?
@Peter_S wrote:
That means for a streaming network:
- one sender (DAQ System -> Flatten to String -> udp multicast sender)
- many receiver (udp multicast receiver -> Unflatten from String)
The sender app can not upgraded with a newer Labview runtime version until all receiver apps are also upgraded.
That is generally true for most client-server situations in one way or the other, though many times it is the other way around where the client negotiates at connection time the highest protocol version it supports and the server downgrades the protocol for that session to this version.
Since the flatten data stream protocol is not strictly a client server protocol and does not have a context like a session in a network connection, it would be pretty troublesome to support such an adaptable protocol negotiation.
You can of course implement it yourself in your server by using the VI (<vilib>\Utility\VariantFlattenExp.vi.) links you found. When your client connects it informs the server about the version it expects and your server stores that version along with the connection refnum somehow and then when you want to Flatten some data to send to the client you use this version number to get the data into the right flattened format for this client.
But generally, if you ever intend to use something like this in a heterogenous solution where the version of your client and server is not guaranteed to be the same, it would seem wiser to simply avoid variants (and waveforms) altogether in any interapplication communication scheme. Same of course but much stronger if you foresee that you will need to communicate with other clients than just LabVIEW built applications!
