Open rdp137 opened 5 years ago
I'm pretty sure this is intentional. While the actual TCP/UDP headers may contain size information in them that's accessible when working with raw sockets, we don't typically have access to those headers when working with LabVIEW. To avoid error-prone string length checks (or otherwise), it's generally good practice to embed the size value in the first few bytes in the data portion of serialized payloads in LabVIEW.
I can see this being problematic is some contexts. Is there a reason you can't strip out that size field at the receiver? Or is it presenting an issue outside of that? Generally, the receivers in this custom device rely on that field to be present for critical functions.
For me, I do a lot of HIL work with this custom device and the hardware on the other end is usually out of my control so when I send a message that has an unexpected byte its game over. When I use a buffered packet I do not see this extra packet so that has been my workaround. That requires me to make an additional model that takes in the channel data and stores it into a buffer. It seems like the plumbing is there to make the data size packet optional, no?
I kind of figured that might be your answer. A lot of the individuals I have worked with (I do a lot of HIL systems as well) have typically used a model pass-through after the receiver or before the transmitter. This is usually for custom packet formatting/parsing of many varieties.
That being said, as this is a standard feature of the custom device, I just want to make sure I understand the value in making it optional. It's a fairly small effort to make it an optional setting. I'll see if I can make that setting optional on my own fork for you.
I am seeing the U16 packet size in my data. I cannot remove packet size and it does not appear to be in the UDP headed but rather in my data. I do not see packet size when I use a buffer