Refactor the feedback loop in Casper to improve message queuing and processing

Description

This work is the outcome of RChain-3578 which investigated the increase in time to propose. The recommendation was to improve the Casper feedback loop.

When Casper is missing some dependencies, it will ask for it using CommUtil.sendBlockRequest.

1 2 3 4 5 6 7 [info] CommUtil [info] sendBlockRequest [info] if given block was already requested [info] - should do nothing (pending) [info] if given block was not yet requested [info] - broadcast HasBlockRequest to random peers (pending) [info] - should log to INFO that request was made (pending)

Only node in state Running will answer messages of type HasBlockRequest

1 2 3 4 5 6 info] Running [info] handleHasBlockRequest [info] if given block is stored in BlockStore [info] - should send back HasBlock message to the sender (pending) [info] if given block is not stored in BlockStore [info] - should do nothing (pending)

Only node in state Running will answer messages of type HasBlock

1 2 3 4 5 info] Running.handleHasBlock [info] - should not request block if casper contains block (259 milliseconds) [info] - should ignore if requested before for the same peer (9 milliseconds) [info] - should store on a waiting list and don't request if requested by different peer (9 milliseconds) [info] - should request block and store information about requested block (126 milliseconds)

Entries from requested blocks must be "maintained". If a block was requested, but data is not received in some defined timeout, a request must be sent to a peer from a waitinglist.

1 2 3 4 5 6 7 8 /** TODO * - periodically check the lists of requests and checks if we waited to long * - if waited to long and there is at least onee peer on waiting list: * - request the block from that peer from waiting list * - move the peer from the waiting list to the requested list * - if the waiting list is empty, log a warning (this means most likely things are not going the way they should), and remove the entry from the list (casper will have to rerequest it) */

Entries from requested blocks can be removed once the block is added by casper

1 2 3 4 [info] Running [info] handleBlockMessage [info] - should remove entry from requested blocks if given block was added to casper (pending) [info] - should NOT remove entry from requested blocks if given block was NOT added to casper (pending)

 

Status

Assignee

Pawel Szulc

Reporter

Kelly Foster

Components

Story Points

8

Epic Link

None

Labels

None

Sprint

None

Priority

Medium