You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when handling a block request we append the newly requested block ids to the queue of previously requested ones, which makes it impossible for the peer to "change its mind" about what blocks it wants to download. Also, because the queue has a size limit, the peer has to download previously requested blocks before even making a new block request.
At this moment this is not an issue, because nodes never send a block request until the previous one is fulfilled. However, in the future we're going to optimize block downloading and peers will need an ability to cancel downloading a block that has already been downloaded from another peer.
A possible solution might be to make a new block request effectively cancel the previous one, overwriting the corresponding queue instead of appending to it.
The text was updated successfully, but these errors were encountered:
Currently when handling a block request we append the newly requested block ids to the queue of previously requested ones, which makes it impossible for the peer to "change its mind" about what blocks it wants to download. Also, because the queue has a size limit, the peer has to download previously requested blocks before even making a new block request.
At this moment this is not an issue, because nodes never send a block request until the previous one is fulfilled. However, in the future we're going to optimize block downloading and peers will need an ability to cancel downloading a block that has already been downloaded from another peer.
A possible solution might be to make a new block request effectively cancel the previous one, overwriting the corresponding queue instead of appending to it.
The text was updated successfully, but these errors were encountered: