Protocol options #85
Merged
Protocol options #85
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
John-LittleBearLabs
force-pushed
the
msg
branch
from
b1c01fe
to
56d7a97
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduce Sync protocol.
The binary can be built supporting both shipper (legacy) & sync, or just one or the other. By default I build ground (big) software with both, and 2 vehicle flavors (one of each). There is now some handshaking so a myceli with both knows which messages to send.
Sync is designed to produce fewer packets (in total) for the same transfer(s) on average, and especially when packets are getting dropped. There is an average decrease in total bytes transferred as well, though packet savings is higher as it's more aggressive about fitting bytes into packets tightly.
On a very good connection, it usually involves more packets in the vehicle->ground direction.