simplify block range request description

[arnetheduck]

There's room for ambiguity as to what count means - this clarifies
that it always relates to the slot, and not the number of blocks in the
response which allows clients to request ranges epoch by epoch (for
example) without worrying about overlaps caused by empty slots.

[arnetheduck]

ping @AgeManning

[djrtwo]

This looks good to me

[AgeManning]

Yeah looks good to me, sorry I was late to the party.

@arnetheduck - Are you guys also syncing blocks epoch per epoch? A sneaky optimisation perhaps?

[arnetheduck]

We don't have it implemented yet, but there are three straightforward optimizations I can think of:

• queue up 1 extra request - ie while receiving 1 epoch, send the next request to the peer already - this saves the roundtrip latency
• time response and adjust request size accordingly - basically, ask for more epochs if peer is fast
• if a request is taking long, send the same request to a second peer, if that's the last thing you need - the way to do this is to assign priorities to block ranges and having a threshold when the same range is re-requested (this is often done in bittorrent for example to get the last few pieces of the file)