Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
ACK feature #215
This PR is based on #130 but adds:
The original technique in the ACK PR mostly works but creates a bit of extra noise with false positives. This extra noise would probably not be too much of an issue in practice for many use cases because any ACK'd records would also be present on the remote machine (if the remote is being honest). But setting the length to 0 for ACKs avoids this noise. A better option might be to add a special type for ACK messages, but this patch works with that is currently available in hypercore-protocol.
There are some legacy cases for length=0 in HAVEs but the ACK cases are narrow and only reachable when ACK is enabled and a bitfield is not set on the HAVE, which the legacy branch seems to expect.
If this patch is accepted it would be good to document the convention it depends on, where a HAVE with length=0 and no bitfield is considered an ACK. This also means that ACKs are limited to acknowledging individual sequences, not whole ranges at a time (since the length field is set to zero). Negative values could be used, but at that point I think it would be better to have a dedicated ACK message type.