Skip to content
This repository has been archived by the owner on Nov 15, 2019. It is now read-only.

closes #835: update bootstrap cache on msg send #1132

Conversation

povilasb
Copy link
Contributor

Move peer to the top of the bootstrap cache, if we are sending a message to it. That means this peer is the most active.

@povilasb povilasb force-pushed the update-bootstrap-cache-on-msg-send branch 3 times, most recently from 8ea0722 to bc6d712 Compare February 25, 2019 10:25
@povilasb povilasb closed this Feb 25, 2019
@povilasb povilasb force-pushed the update-bootstrap-cache-on-msg-send branch from bc6d712 to 84f378a Compare February 25, 2019 10:55
@povilasb povilasb reopened this Feb 25, 2019
@povilasb povilasb force-pushed the update-bootstrap-cache-on-msg-send branch from 2284316 to f9b5998 Compare February 25, 2019 14:41
@povilasb povilasb mentioned this pull request Feb 25, 2019
@povilasb povilasb changed the title Update bootstrap cache on msg send closes #835: update bootstrap cache on msg send Feb 25, 2019
@povilasb povilasb force-pushed the update-bootstrap-cache-on-msg-send branch from f9b5998 to b206d42 Compare February 26, 2019 08:18
}
Ok(Some(message)) => {
debug!("{:?} - Unexpected message: {:?}", self.our_id, message);
self.reset_receive_heartbeat(core, poll);
self.updated_bootstrap_cache(core, poll);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are we updating it in a loop ? Wouldn't it be better to do it for Ok(None) case only (so opposite of what you've done here) ? That way most of the time it's triggered only after all the reading has been done for this time from the peer (instead of after every call of the sock-coll read which might be returning things from buffer).

If we are very pernickety, then we might say there might be spurious wake ups and read called without there being anything to actually read which will also return Ok(None) . For that either live with it OR have some sort of a bool before the loop and toggle it once anything legit is read and then check that in Ok(None) and update the BStrap cache there. Doing it in a loop seems wasteful other wise (and unfair too in a way as theoretically all the msgs could have been read and buffered by the sock-coll internally which does not mean that peer is still sending when we are reading the next time in the loop - so timestamp shouldn't be updated)

ustulation
ustulation previously approved these changes Feb 27, 2019
…ate with it

When a packet is senat or received from remote peer that was previously
put in bootstrap cache, make sure we let the cache know that the peer is
active.
When messages are received from connection, peer is moved to the top of bootstrap cache.
If we receive multiple messages at once, make sure we move peer in cache only once.
@povilasb
Copy link
Contributor Author

Deprecated in favor of #1138

@povilasb povilasb closed this Feb 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants