-
Notifications
You must be signed in to change notification settings - Fork 112
feat(sessions): add rebroadcasting, search backoff #133
Conversation
AAAND there's a data race, so, um, better go ahead and do that refactor after all :) |
JK not gonna refactor, case that turns out to be complicated and filters all the way up to bitswap and go-ipfs-exchange-interface :( |
58b4db1
to
9b04d41
Compare
Don't count consecutive ticks if there are no active wants
9b04d41
to
e2e3343
Compare
Re-setup provider search delay and rebroadcast delay on a per bitswap instance basis
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Belated review.
// Session run loop -- everything function below here should not be called | ||
// of this loop | ||
func (s *Session) run(ctx context.Context) { | ||
s.tick = time.NewTimer(provSearchDelay) | ||
s.tick = time.NewTimer(s.provSearchDelay) | ||
s.rebroadcast = time.NewTimer(s.rebroadcastDelay.Get()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: I'm not sure using delay.D
is all that useful here as we always just reuse the same initial delay. delay.D
is designed for random delays (we'd need to use a ticker and reset it with rebroadcast.Reset(s.rebroadcastDelay.NextWaitTime())
).
} | ||
} | ||
|
||
func (s *Session) handleRebroadcast(ctx context.Context) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't actually rebroadcast anything, does it? We should probably just call this something like handlePeriodicSearch
.
feat(sessions): add rebroadcasting, search backoff
…r-requests feat(sessions): add rebroadcasting, search backoff This commit was moved from ipfs/go-bitswap@86089ee
Goals
Attempt to kill two birds with one stone:
Implemenation
Start tracking whether a tick is "consecutive" -- i.e no new unique blocks have been received since the last tick. On consecutive ticks do two things different:
It might be a problem to never go looking for providers for the same block again but...
By adding a very periodic search for more providers no matter what (i.e. 1 minute -- mirroring the rebroadcast time in pre-sessions bitswap), there is a last ditch insurance policy that you'll keep looking for providers just in case they appear.
And, as a bonus, this means if you are receiving blocks but have slow providers, eventually you'll go looking for faster ones.
Ideally:
fix #95, fix #107
For discussion
At this point, the global options SetProviderSearchDelay & SetRebroadcastDelay are starting to get to be a smell (need options on sessions) and need a refactor but this is a subtle enough change I wanted it evaluated on its own.