Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packet Size in data bytes #45

Open
rdp137 opened this issue Sep 6, 2019 · 3 comments
Open

Packet Size in data bytes #45

rdp137 opened this issue Sep 6, 2019 · 3 comments

Comments

@rdp137
Copy link

rdp137 commented Sep 6, 2019

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

@ryanvallieres
Copy link
Contributor

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.

@rdp137
Copy link
Author

rdp137 commented Oct 15, 2019

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?

@ryanvallieres
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants