TCP packet while loop

[CoastalMaineBird]

I remember now that you need to send a length first then the actual data in Java/C++ etc etc.

This is not a requirement of the language, it has nothing to do with what language you use. It is part of the protocol YOU decided to use. It is YOUR convention to do that (though it is a common convention). If you know that the cluster will always be 897 bytes long, then it's fine to just send the 897 bytes, without doing the two-step. But it's more flexible to announce what's coming before you send it - that way, if an array is changing size from one transmission to the next, it's accounted for.

[CoastalMaineBird]

One more thing - I believe Java handles strings in Unicode. If you try to send a string over the fence, It's possible that Java will tell you that the string is 10 characters long, then transmit 20 bytes of data. That's because a character is two bytes in Unicode. LabVIEW will puke on that.
I would scratch the string idea from the examples I gave you - your real app doesn't need strings anyway.

[King Cosmos]

I am still having difficulty getting the cluster logic to work correctly from the Java server to the LabVIEW client. Here is a snippit of my Java code. I am sending two integers:

try {
int a = 10;
int b = 15;

OutputStream out = nextClient.getOutputStream();
PrintStream pout = new PrintStream(out);

pout.print(a);
pout.print(b);

out.flush();
out.close();
nextClient.close();
}

The client VI I have attached will not read the integers in the unflattened cluster of the string received via TCP read. Now, if I convert the string directly from the TCP read and display it, it will show up for a split second in the output display then disappear. Arrrgh!

[CoastalMaineBird]

Remember that how many bytes you send, and how many bytes you receive MUST agree. That's the reason for the two step - they will never get out of sync that way.

Without the two-step, you have to manage that yourself.

In your example, you send 8 bytes, but only receive 4.

You then take that 4-byte string and unflatten it to a cluster of two I32s - I'll wager a dollar to a doughnut that the ERR output of the unflatten function is telling you something. But you're not hearing it.