LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Flatten to JSON, XML, or string to communicate across a network?

Solved!
Go to solution

I am working on a client/server system and I want to pass an array of clusters from a LabVIEW server to a LabVIEW client on another computer. Any of these three flatten/unflatten strategies should work, which one is most robust? Since TCP is supposed to be lossless, it shouldn't matter, but I'm sure that some people have had better success with one method than the others.

0 Kudos
Message 1 of 5
(2,650 Views)
Solution
Accepted by StevenHunter

String is basically illegible to the naked eye if you ever need to do debugging via network traffic snooping, so I would say that makes it "less robust".

 

JSON and string flattening basically explode and stop working if there's ever a type definition change on one side not matched on the other.  Not a problem if you can be sure you always update the client and server models at the same time.

 

JSON's "flatten" function doesn't work for classes despite having an "anything" input, so if you ever want to pass classes instead of clusters, no luck.

 

LabVIEW's XML encoding for classes includes version control that can read old versions of the class, allowing for a partially out-of-sync updating, if some classes only are sent one way.

 

So I would give the edge to XML here.

 

Edit because I forgot another alternative:

 

If you use the INI file format and just send that over TCP/IP, you don't get errors until you look for a value that doesn't exist, making mismatched versions even less of an issue.  

OpenG has VIs in it that can read/write clusters as INI files, to partially automate the process.

Message 2 of 5
(2,628 Views)

Great information. I will use Flatten to XML.

0 Kudos
Message 3 of 5
(2,618 Views)

If only LabVIEW had inbuilt support for ProtoBuf, that would be the best solution.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
0 Kudos
Message 4 of 5
(2,601 Views)

anytime NI would like to support protobufs, please go ahead. Creating a protobuf compiler for LV is big task, but if anyone can do it it's NI

Message 5 of 5
(2,306 Views)