Sending Objects over TCP/IP

[Stagg54]

I'm starting this new project where I have to send some objects over TCP/IP. I'm planning on flattening it to a string on one side and then unflattening it on the other. So far I haven't run into any problems, but I've only really tried it in the development environment with 2 vis on the same local machine. I'm basically using the command pattern to send commands over a TCP/IP link so I'm counting on the recieving end to recreate the correct child class, which it appears to be doing.

The only potential issue I am aware of is making sure both sides have the same class definitions

What other issues might I run into?

I'm sending the objects from a Windows box running a exe built with LV2010 64bit and I'm sending it to a RT box running an exe built in LV2010RT 32bit. Can I make this work in that situation? Is the 64 vs 32 bit going to create any problems?

[Tim_S]

I'm sending an object between executables in LV 8.6.1. So far it also works in 2011. I haven't run into any issues besides versioning.

Tim

[Jon Kokott]

I've done it, it worked. I was using identical binaries on different machines, all of which ran lv2010 sp1. In the future I would probably try to load the class directly from one disc location for both instances using either the load class from path primitive or copying the actual file (probably in a packed library or .llb) and running it that way.

[drjdpowell]

By coincidence I'm working on a similar thing right now: Message objects via TCP. Like you, I've mostly done two VIs on the same machine (except for one brief proof-of-principle test between England and California which worked fine). The one issue I can add is the rather large size of flattened objects, especially objects that contain other objects (which might contain even more objects). Sending a simple "Hello World" as one of my Message objects flattens to an embarrassing 75 bytes, while the "SendTimeString" message in my linked post (which has a complex 7-object reply address) flattens to 547 bytes! I've just started using the ZLIB string compression (OpenG ZIP Tools) and that seems to be a help with the larger objects (compresses the 547 bytes down to 199). I've also made a custom flattening of the more common objects to get the size down ("Hello World" becomes 17 bytes).

-- James

[Aristos Queue]

The bytes used are because classes carry with them their type information which is what enables the significantly more powerful flattening/unflattening abilities over and above raw data.

[ShaunR]

By coincidence I'm working on a similar thing right now: Message objects via TCP. Like you, I've mostly done two VIs on the same machine (except for one brief proof-of-principle test between England and California which worked fine). The one issue I can add is the rather large size of flattened objects, especially objects that contain other objects (which might contain even more objects). Sending a simple "Hello World" as one of my Message objects flattens to an embarrassing 75 bytes, while the "SendTimeString" message in my linked post (which has a complex 7-object reply address) flattens to 547 bytes! I've just started using the ZLIB string compression (OpenG ZIP Tools) and that seems to be a help with the larger objects (compresses the 547 bytes down to 199). I've also made a custom flattening of the more common objects to get the size down ("Hello World" becomes 17 bytes).

-- James

If you use the transport.lib in the cr, it will give you transparent zlib compression (as well as encryption, send timestamps and throughput) across tcpip, udp and Bluetooth.Might be useful.