Idle tick behaviour

[dirkmc]

Current Behaviour

When a Session gets an idle tick (it hasn't received any blocks for a while) it

• broadcasts want-have for all wants that were ever requested
• queries the DHT for the first requested CID

However the wants are stored in a map, so the "first" CID is actually random (because golang randomizes the order of iteration over a map)

Proposal

When there is an idle tick:

• broadcast want-have for all wants for which we haven't received a block (rather than all wants ever requested)
• query the DHT for the first want that has not yet been received (rather than a random want / the first want ever requested)

[Stebalien]

broadcasts want-have for all wants that were ever requested

You sure? I think we broadcast live wants (which shouldn't include wants for which we have already received blocks, as far as I know).

query the DHT for the first want that has not yet been received (rather than a random want / the first want ever requested)

Asking for the first want may work better in some cases, but asking for a random one may work better when we can't find a specific block. Ideally, we'd try them sequentially if that's not too hard.

[dirkmc]

I think we broadcast live wants (which shouldn't include wants for which we have already received blocks, as far as I know)

That's what I would have assumed, but I think there's actually a bug (probably introduced by the recent refactor) whereby the current behaviour is that the Session broadcasts wants for all blocks that have ever been requested.
Nevermind I think it's actually not including wants for which we've already received blocks, but the list is not size-limited.

It should instead have a dynamic, limited size list where

• wants are added to the end of the list as the client requests blocks and wants are sent out
• wants are dropped from the broadcast list as the corresponding blocks are received,
  and the list is refilled with live wants

Asking for the first want may work better in some cases

I'm not sure if that will work better. For example many peers may have the root block of a DAG, but the Session removes those peers if they send many DONT_HAVEs (because they don't have lower branches of the DAG). So in that case we wouldn't want to broadcast a request for the root block, only for the parts of the DAG that we haven't been able to retrieve.

Note that we do also periodically broadcast and query the DHT for a random live want.