try harder to not send duplicate blocks - #1166
Conversation
|
should write a test case for it |
|
@jbenet I've been trying to think about how to work this into a test. The problem i'm having is that we only see the issue on higher latency connections, otherwise the cancels arrive in a timely manner and do their job of preventing duplicate sends. So finding a way to repro this is what ill be working on today |
|
There's a way to add latency to mocknet or something. Take a look at the epic/ tests. |
|
@whyrusleeping I think the dialer / net stuff should be its own PR? |
|
Yeah, i was just hacking on the same branch. Ill break it up in a little bit |
757cd48 to
f998339
Compare
There was a problem hiding this comment.
move this into ReceiveMessage, dont log, but maybe record statistics to be printed out by ipfs bitswap stat
|
update here? |
|
@jbenet this is RFCR |
|
@whyrusleeping LGTM |
try harder to not send duplicate blocks
* chore: bump boxo to test ipfs/boxo#1166 Bumps github.com/ipfs/boxo to the tip of fix/ipns-cache-control-expiry (55fd621d1872) to exercise the IPNS cache-control/TTL/EOL fixes from ipfs/boxo#1166. Root, docs/examples, and test/dependencies modules tidied via make mod_tidy. Signed-off-by: Marcin Rataj <lidel@lidel.org> * fix: validate ipns lifetime and ttl settings ipfs name publish now sanitizes its duration flags instead of emitting a record that fails verification later: a non-positive --lifetime and a negative --ttl are rejected, an explicit --ttl over --lifetime is rejected, and an omitted --ttl is capped to --lifetime. The --lifetime and --ttl defaults are applied server-side so an explicit value is distinguishable from the default. The daemon also refuses to start when Ipns.RecordLifetime is shorter than Ipns.RepublishPeriod, which would let records expire before they are republished. Signed-off-by: Marcin Rataj <lidel@lidel.org> * switch to boxo@main with fix #1166 --------- Signed-off-by: Marcin Rataj <lidel@lidel.org> Co-authored-by: gammazero <11790789+gammazero@users.noreply.github.com>
2 participants
I havent tested this in the field yet, need to get some better metrics in place first. But this should help out quite a bit with transfer speeds, if my hunch is correct.