-
Notifications
You must be signed in to change notification settings - Fork 24
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
Revisit the binary protocol between RTI and federates #410
Comments
This sounds like a good idea to me. Perhaps @Jakio815 could comment on how to make this compatible with encryption. |
I kind of didn't understand fully. So, we have lots of types of messages going on, you mean we should kind of make a fixed structure of message used in every message? I didn't get what you mean the 'magic start and end bytes'. @erlingrj |
Yes, I would propose to have all messages start with the same header. By magic byte start/end bytes I mean that we should pick some random bytes to serve as delimiters. E.g. we could pick |
@erlingrj I've got some questions, and I will be able to work on this from next week. I have two questions.
|
The measures I am outlining is meant to catch runtime bugs and application bugs. So they are not needed if the code is perfect. Magic bytes and header checksums makes it very likely that the you in fact have a valid message. It would have caught the error here: #409 |
The current binary protocol between RTI and federates is somewhat brittle. Different packages are identified by just a magic byte. Another bug #409 lead to the RTI decoding arbitrary messages from the incoming socket. It would not have been a problem if the binary protocol was a little more robust. E.g we could do:
| magic start bytes | msg_type | length | header checksum | data | magic stop bytes |
This is just a quick idea, we can argue what would be the best protocol. But I do not think we should worry a lot about adding a couple of bytes to each package if it increases the robustness.
The text was updated successfully, but these errors were encountered: