Skip to content

Store a cached NodeId for each Peer - #2022

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
alecchendev:2023-02-cache-peer-nodeid
Feb 8, 2023
Merged

Store a cached NodeId for each Peer#2022
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
alecchendev:2023-02-cache-peer-nodeid

Conversation

@alecchendev

@alecchendevalecchendev commented Feb 8, 2023

Copy link
Copy Markdown
Contributor

Closes#2021 as a followup on #2016.

Converts Peer field their_node_id: Option<PublicKey> to Option<(PublicKey, NodeId)> to avoid redundantly serializing peer public keys when forwarding gossip messages.

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment on lines +392 to +398
// When setting this field to a `Some(..)` value, use `Peer::set_their_node_id` to also set
// the following field `their_node_id_serialized`.
their_node_id: Option<PublicKey>,
// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
// time we forward gossip messages in `PeerManager`. It should be set anytime `their_node_id`
// gets set.
their_node_id_serialized: Option<NodeId>,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm a bit worried these could go out of sync, but doc comments which would at least appear in most author IDEs could help with that if there's no better way (which I can't think of right now). Unfortunately, single fields cannot be made externally immutable in Rust. I'm sure others might have some experience here. :)

Suggested change
// When setting this field to a `Some(..)` value, use `Peer::set_their_node_id` to also set
// the following field `their_node_id_serialized`.
their_node_id:Option<PublicKey>,
// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
// time we forward gossip messages in `PeerManager`. It should be set anytime `their_node_id`
// gets set.
their_node_id_serialized:Option<NodeId>,
/// NOTE: Do not modify this field directly. Use `Peer::set_their_node_id` instead.
their_node_id:Option<PublicKey>,
/// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
/// time we forward gossip messages in `PeerManager`.
///
/// NOTE: Do not modify this field directly. Use `Peer::set_their_node_id` instead.
their_node_id_serialized:Option<NodeId>,

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Oh oops I meant to make them doc comments, thanks. And yea those were exactly my thoughts, at the moment I can't think of a way to cache without risking them going out of sync, hoping this would have the least friction for keeping them in sync.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We could make their_node_id a tuple (PublicKey, NodeId), that way you're forced to update them in tandem.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Aha! Simple :)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Doesn't avoid the possibility of a mismatch but better than two fields.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Oh nice! Will update

@alecchendev
alecchendevforce-pushed the 2023-02-cache-peer-nodeid branch from b6b52a9 to 08e9bc3CompareFebruary 8, 2023 16:56
@codecov-commenter

codecov-commenter commented Feb 8, 2023

Copy link
Copy Markdown

Codecov Report

Base: 91.04% // Head: 91.06% // Increases project coverage by +0.02% 🎉

Coverage data is based on head (b6b52a9) compared to base (56146e7).
Patch coverage: 72.72% of modified lines in pull request are covered.

❗ Current head b6b52a9 differs from pull request most recent head 4c1055d. Consider uploading reports for the commit 4c1055d to get more accurate results

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files
@@ Coverage Diff @@## main #2022 +/- ##
==========================================
+ Coverage 91.04% 91.06% +0.02% 
==========================================
Files 99 99 Lines 51722 51727 +5 Branches 51722 51727 +5 ==========================================
+ Hits 47090 47107 +17 + Misses 4632 4620 -12 
Impacted FilesCoverage Δ
lightning/src/ln/chan_utils.rs93.57% <ø> (ø)
lightning/src/ln/peer_handler.rs55.84% <72.72%> (+0.34%)⬆️
lightning/src/util/events.rs29.56% <0.00%> (-0.24%)⬇️
lightning/src/ln/channelmanager.rs87.43% <0.00%> (+0.02%)⬆️
lightning/src/ln/functional_tests.rs97.07% <0.00%> (+0.16%)⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

This is done to avoid redundantly serializing peer node
ids when forwarding gossip messages in
`PeerManager::forward_broadcast_msg`.
@alecchendev
alecchendevforce-pushed the 2023-02-cache-peer-nodeid branch from 08e9bc3 to 4c1055dCompareFebruary 8, 2023 17:58

@dunxendunxen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This LGTM. Nice one!

@TheBlueMatt
TheBlueMatt merged commit 137b77c into lightningdevkit:mainFeb 8, 2023
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Store a cached NodeId for each of our Peers in PeerManager.

5 participants

@alecchendev@codecov-commenter@TheBlueMatt@dunxen@wpaulino
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Store a cached `NodeId` for each `Peer` by alecchendev · Pull Request #2022 · lightningdevkit/rust-lightning · GitHub
Skip to content

Store a cached NodeId for each Peer - #2022

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
alecchendev:2023-02-cache-peer-nodeid
Feb 8, 2023
Merged

Store a cached NodeId for each Peer#2022
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
alecchendev:2023-02-cache-peer-nodeid

Conversation

@alecchendev

@alecchendevalecchendev commented Feb 8, 2023

Copy link
Copy Markdown
Contributor

Closes#2021 as a followup on #2016.

Converts Peer field their_node_id: Option<PublicKey> to Option<(PublicKey, NodeId)> to avoid redundantly serializing peer public keys when forwarding gossip messages.

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment on lines +392 to +398
// When setting this field to a `Some(..)` value, use `Peer::set_their_node_id` to also set
// the following field `their_node_id_serialized`.
their_node_id: Option<PublicKey>,
// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
// time we forward gossip messages in `PeerManager`. It should be set anytime `their_node_id`
// gets set.
their_node_id_serialized: Option<NodeId>,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm a bit worried these could go out of sync, but doc comments which would at least appear in most author IDEs could help with that if there's no better way (which I can't think of right now). Unfortunately, single fields cannot be made externally immutable in Rust. I'm sure others might have some experience here. :)

Suggested change
// When setting this field to a `Some(..)` value, use `Peer::set_their_node_id` to also set
// the following field `their_node_id_serialized`.
their_node_id:Option<PublicKey>,
// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
// time we forward gossip messages in `PeerManager`. It should be set anytime `their_node_id`
// gets set.
their_node_id_serialized:Option<NodeId>,
/// NOTE: Do not modify this field directly. Use `Peer::set_their_node_id` instead.
their_node_id:Option<PublicKey>,
/// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
/// time we forward gossip messages in `PeerManager`.
///
/// NOTE: Do not modify this field directly. Use `Peer::set_their_node_id` instead.
their_node_id_serialized:Option<NodeId>,

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Oh oops I meant to make them doc comments, thanks. And yea those were exactly my thoughts, at the moment I can't think of a way to cache without risking them going out of sync, hoping this would have the least friction for keeping them in sync.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We could make their_node_id a tuple (PublicKey, NodeId), that way you're forced to update them in tandem.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Aha! Simple :)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Doesn't avoid the possibility of a mismatch but better than two fields.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Oh nice! Will update

@alecchendev
alecchendevforce-pushed the 2023-02-cache-peer-nodeid branch from b6b52a9 to 08e9bc3CompareFebruary 8, 2023 16:56
@codecov-commenter

codecov-commenter commented Feb 8, 2023

Copy link
Copy Markdown

Codecov Report

Base: 91.04% // Head: 91.06% // Increases project coverage by +0.02% 🎉

Coverage data is based on head (b6b52a9) compared to base (56146e7).
Patch coverage: 72.72% of modified lines in pull request are covered.

❗ Current head b6b52a9 differs from pull request most recent head 4c1055d. Consider uploading reports for the commit 4c1055d to get more accurate results

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files
@@ Coverage Diff @@## main #2022 +/- ##
==========================================
+ Coverage 91.04% 91.06% +0.02% 
==========================================
Files 99 99 Lines 51722 51727 +5 Branches 51722 51727 +5 ==========================================
+ Hits 47090 47107 +17 + Misses 4632 4620 -12 
Impacted FilesCoverage Δ
lightning/src/ln/chan_utils.rs93.57% <ø> (ø)
lightning/src/ln/peer_handler.rs55.84% <72.72%> (+0.34%)⬆️
lightning/src/util/events.rs29.56% <0.00%> (-0.24%)⬇️
lightning/src/ln/channelmanager.rs87.43% <0.00%> (+0.02%)⬆️
lightning/src/ln/functional_tests.rs97.07% <0.00%> (+0.16%)⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

This is done to avoid redundantly serializing peer node
ids when forwarding gossip messages in
`PeerManager::forward_broadcast_msg`.
@alecchendev
alecchendevforce-pushed the 2023-02-cache-peer-nodeid branch from 08e9bc3 to 4c1055dCompareFebruary 8, 2023 17:58

@dunxendunxen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This LGTM. Nice one!

@TheBlueMatt
TheBlueMatt merged commit 137b77c into lightningdevkit:mainFeb 8, 2023
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Store a cached NodeId for each of our Peers in PeerManager.

5 participants

@alecchendev@codecov-commenter@TheBlueMatt@dunxen@wpaulino
, 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Store a cached `NodeId` for each `Peer` by alecchendev · Pull Request #2022 · lightningdevkit/rust-lightning · GitHub
Skip to content

Store a cached NodeId for each Peer - #2022

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
alecchendev:2023-02-cache-peer-nodeid
Feb 8, 2023
Merged

Store a cached NodeId for each Peer#2022
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
alecchendev:2023-02-cache-peer-nodeid

Conversation

@alecchendev

@alecchendevalecchendev commented Feb 8, 2023

Copy link
Copy Markdown
Contributor

Closes#2021 as a followup on #2016.

Converts Peer field their_node_id: Option<PublicKey> to Option<(PublicKey, NodeId)> to avoid redundantly serializing peer public keys when forwarding gossip messages.

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment on lines +392 to +398
// When setting this field to a `Some(..)` value, use `Peer::set_their_node_id` to also set
// the following field `their_node_id_serialized`.
their_node_id: Option<PublicKey>,
// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
// time we forward gossip messages in `PeerManager`. It should be set anytime `their_node_id`
// gets set.
their_node_id_serialized: Option<NodeId>,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm a bit worried these could go out of sync, but doc comments which would at least appear in most author IDEs could help with that if there's no better way (which I can't think of right now). Unfortunately, single fields cannot be made externally immutable in Rust. I'm sure others might have some experience here. :)

Suggested change
// When setting this field to a `Some(..)` value, use `Peer::set_their_node_id` to also set
// the following field `their_node_id_serialized`.
their_node_id:Option<PublicKey>,
// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
// time we forward gossip messages in `PeerManager`. It should be set anytime `their_node_id`
// gets set.
their_node_id_serialized:Option<NodeId>,
/// NOTE: Do not modify this field directly. Use `Peer::set_their_node_id` instead.
their_node_id:Option<PublicKey>,
/// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
/// time we forward gossip messages in `PeerManager`.
///
/// NOTE: Do not modify this field directly. Use `Peer::set_their_node_id` instead.
their_node_id_serialized:Option<NodeId>,

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Oh oops I meant to make them doc comments, thanks. And yea those were exactly my thoughts, at the moment I can't think of a way to cache without risking them going out of sync, hoping this would have the least friction for keeping them in sync.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We could make their_node_id a tuple (PublicKey, NodeId), that way you're forced to update them in tandem.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Aha! Simple :)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Doesn't avoid the possibility of a mismatch but better than two fields.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Oh nice! Will update

@alecchendev
alecchendevforce-pushed the 2023-02-cache-peer-nodeid branch from b6b52a9 to 08e9bc3CompareFebruary 8, 2023 16:56
@codecov-commenter

codecov-commenter commented Feb 8, 2023

Copy link
Copy Markdown

Codecov Report

Base: 91.04% // Head: 91.06% // Increases project coverage by +0.02% 🎉

Coverage data is based on head (b6b52a9) compared to base (56146e7).
Patch coverage: 72.72% of modified lines in pull request are covered.

❗ Current head b6b52a9 differs from pull request most recent head 4c1055d. Consider uploading reports for the commit 4c1055d to get more accurate results

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files
@@ Coverage Diff @@## main #2022 +/- ##
==========================================
+ Coverage 91.04% 91.06% +0.02% 
==========================================
Files 99 99 Lines 51722 51727 +5 Branches 51722 51727 +5 ==========================================
+ Hits 47090 47107 +17 + Misses 4632 4620 -12 
Impacted FilesCoverage Δ
lightning/src/ln/chan_utils.rs93.57% <ø> (ø)
lightning/src/ln/peer_handler.rs55.84% <72.72%> (+0.34%)⬆️
lightning/src/util/events.rs29.56% <0.00%> (-0.24%)⬇️
lightning/src/ln/channelmanager.rs87.43% <0.00%> (+0.02%)⬆️
lightning/src/ln/functional_tests.rs97.07% <0.00%> (+0.16%)⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

This is done to avoid redundantly serializing peer node
ids when forwarding gossip messages in
`PeerManager::forward_broadcast_msg`.
@alecchendev
alecchendevforce-pushed the 2023-02-cache-peer-nodeid branch from 08e9bc3 to 4c1055dCompareFebruary 8, 2023 17:58

@dunxendunxen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This LGTM. Nice one!

@TheBlueMatt
TheBlueMatt merged commit 137b77c into lightningdevkit:mainFeb 8, 2023
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Store a cached NodeId for each of our Peers in PeerManager.

5 participants

@alecchendev@codecov-commenter@TheBlueMatt@dunxen@wpaulino
, 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Store a cached `NodeId` for each `Peer` by alecchendev · Pull Request #2022 · lightningdevkit/rust-lightning · GitHub
Skip to content

Store a cached NodeId for each Peer - #2022

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
alecchendev:2023-02-cache-peer-nodeid
Feb 8, 2023
Merged

Store a cached NodeId for each Peer#2022
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
alecchendev:2023-02-cache-peer-nodeid

Conversation

@alecchendev

@alecchendevalecchendev commented Feb 8, 2023

Copy link
Copy Markdown
Contributor

Closes#2021 as a followup on #2016.

Converts Peer field their_node_id: Option<PublicKey> to Option<(PublicKey, NodeId)> to avoid redundantly serializing peer public keys when forwarding gossip messages.

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment on lines +392 to +398
// When setting this field to a `Some(..)` value, use `Peer::set_their_node_id` to also set
// the following field `their_node_id_serialized`.
their_node_id: Option<PublicKey>,
// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
// time we forward gossip messages in `PeerManager`. It should be set anytime `their_node_id`
// gets set.
their_node_id_serialized: Option<NodeId>,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm a bit worried these could go out of sync, but doc comments which would at least appear in most author IDEs could help with that if there's no better way (which I can't think of right now). Unfortunately, single fields cannot be made externally immutable in Rust. I'm sure others might have some experience here. :)

Suggested change
// When setting this field to a `Some(..)` value, use `Peer::set_their_node_id` to also set
// the following field `their_node_id_serialized`.
their_node_id:Option<PublicKey>,
// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
// time we forward gossip messages in `PeerManager`. It should be set anytime `their_node_id`
// gets set.
their_node_id_serialized:Option<NodeId>,
/// NOTE: Do not modify this field directly. Use `Peer::set_their_node_id` instead.
their_node_id:Option<PublicKey>,
/// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
/// time we forward gossip messages in `PeerManager`.
///
/// NOTE: Do not modify this field directly. Use `Peer::set_their_node_id` instead.
their_node_id_serialized:Option<NodeId>,

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Oh oops I meant to make them doc comments, thanks. And yea those were exactly my thoughts, at the moment I can't think of a way to cache without risking them going out of sync, hoping this would have the least friction for keeping them in sync.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We could make their_node_id a tuple (PublicKey, NodeId), that way you're forced to update them in tandem.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Aha! Simple :)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Doesn't avoid the possibility of a mismatch but better than two fields.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Oh nice! Will update

@alecchendev
alecchendevforce-pushed the 2023-02-cache-peer-nodeid branch from b6b52a9 to 08e9bc3CompareFebruary 8, 2023 16:56
@codecov-commenter

codecov-commenter commented Feb 8, 2023

Copy link
Copy Markdown

Codecov Report

Base: 91.04% // Head: 91.06% // Increases project coverage by +0.02% 🎉

Coverage data is based on head (b6b52a9) compared to base (56146e7).
Patch coverage: 72.72% of modified lines in pull request are covered.

❗ Current head b6b52a9 differs from pull request most recent head 4c1055d. Consider uploading reports for the commit 4c1055d to get more accurate results

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files
@@ Coverage Diff @@## main #2022 +/- ##
==========================================
+ Coverage 91.04% 91.06% +0.02% 
==========================================
Files 99 99 Lines 51722 51727 +5 Branches 51722 51727 +5 ==========================================
+ Hits 47090 47107 +17 + Misses 4632 4620 -12 
Impacted FilesCoverage Δ
lightning/src/ln/chan_utils.rs93.57% <ø> (ø)
lightning/src/ln/peer_handler.rs55.84% <72.72%> (+0.34%)⬆️
lightning/src/util/events.rs29.56% <0.00%> (-0.24%)⬇️
lightning/src/ln/channelmanager.rs87.43% <0.00%> (+0.02%)⬆️
lightning/src/ln/functional_tests.rs97.07% <0.00%> (+0.16%)⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

This is done to avoid redundantly serializing peer node
ids when forwarding gossip messages in
`PeerManager::forward_broadcast_msg`.
@alecchendev
alecchendevforce-pushed the 2023-02-cache-peer-nodeid branch from 08e9bc3 to 4c1055dCompareFebruary 8, 2023 17:58

@dunxendunxen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This LGTM. Nice one!

@TheBlueMatt
TheBlueMatt merged commit 137b77c into lightningdevkit:mainFeb 8, 2023
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Store a cached NodeId for each of our Peers in PeerManager.

5 participants

@alecchendev@codecov-commenter@TheBlueMatt@dunxen@wpaulino
, 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ' Store a cached `NodeId` for each `Peer` by alecchendev · Pull Request #2022 · lightningdevkit/rust-lightning · GitHub
Skip to content

Store a cached NodeId for each Peer - #2022

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
alecchendev:2023-02-cache-peer-nodeid
Feb 8, 2023
Merged

Store a cached NodeId for each Peer#2022
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
alecchendev:2023-02-cache-peer-nodeid

Conversation

@alecchendev

@alecchendevalecchendev commented Feb 8, 2023

Copy link
Copy Markdown
Contributor

Closes#2021 as a followup on #2016.

Converts Peer field their_node_id: Option<PublicKey> to Option<(PublicKey, NodeId)> to avoid redundantly serializing peer public keys when forwarding gossip messages.

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment on lines +392 to +398
// When setting this field to a `Some(..)` value, use `Peer::set_their_node_id` to also set
// the following field `their_node_id_serialized`.
their_node_id: Option<PublicKey>,
// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
// time we forward gossip messages in `PeerManager`. It should be set anytime `their_node_id`
// gets set.
their_node_id_serialized: Option<NodeId>,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm a bit worried these could go out of sync, but doc comments which would at least appear in most author IDEs could help with that if there's no better way (which I can't think of right now). Unfortunately, single fields cannot be made externally immutable in Rust. I'm sure others might have some experience here. :)

Suggested change
// When setting this field to a `Some(..)` value, use `Peer::set_their_node_id` to also set
// the following field `their_node_id_serialized`.
their_node_id:Option<PublicKey>,
// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
// time we forward gossip messages in `PeerManager`. It should be set anytime `their_node_id`
// gets set.
their_node_id_serialized:Option<NodeId>,
/// NOTE: Do not modify this field directly. Use `Peer::set_their_node_id` instead.
their_node_id:Option<PublicKey>,
/// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
/// time we forward gossip messages in `PeerManager`.
///
/// NOTE: Do not modify this field directly. Use `Peer::set_their_node_id` instead.
their_node_id_serialized:Option<NodeId>,

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Oh oops I meant to make them doc comments, thanks. And yea those were exactly my thoughts, at the moment I can't think of a way to cache without risking them going out of sync, hoping this would have the least friction for keeping them in sync.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We could make their_node_id a tuple (PublicKey, NodeId), that way you're forced to update them in tandem.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Aha! Simple :)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Doesn't avoid the possibility of a mismatch but better than two fields.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Oh nice! Will update

@alecchendev
alecchendevforce-pushed the 2023-02-cache-peer-nodeid branch from b6b52a9 to 08e9bc3CompareFebruary 8, 2023 16:56
@codecov-commenter

codecov-commenter commented Feb 8, 2023

Copy link
Copy Markdown

Codecov Report

Base: 91.04% // Head: 91.06% // Increases project coverage by +0.02% 🎉

Coverage data is based on head (b6b52a9) compared to base (56146e7).
Patch coverage: 72.72% of modified lines in pull request are covered.

❗ Current head b6b52a9 differs from pull request most recent head 4c1055d. Consider uploading reports for the commit 4c1055d to get more accurate results

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files
@@ Coverage Diff @@## main #2022 +/- ##
==========================================
+ Coverage 91.04% 91.06% +0.02% 
==========================================
Files 99 99 Lines 51722 51727 +5 Branches 51722 51727 +5 ==========================================
+ Hits 47090 47107 +17 + Misses 4632 4620 -12 
Impacted FilesCoverage Δ
lightning/src/ln/chan_utils.rs93.57% <ø> (ø)
lightning/src/ln/peer_handler.rs55.84% <72.72%> (+0.34%)⬆️
lightning/src/util/events.rs29.56% <0.00%> (-0.24%)⬇️
lightning/src/ln/channelmanager.rs87.43% <0.00%> (+0.02%)⬆️
lightning/src/ln/functional_tests.rs97.07% <0.00%> (+0.16%)⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

This is done to avoid redundantly serializing peer node
ids when forwarding gossip messages in
`PeerManager::forward_broadcast_msg`.
@alecchendev
alecchendevforce-pushed the 2023-02-cache-peer-nodeid branch from 08e9bc3 to 4c1055dCompareFebruary 8, 2023 17:58

@dunxendunxen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This LGTM. Nice one!

@TheBlueMatt
TheBlueMatt merged commit 137b77c into lightningdevkit:mainFeb 8, 2023
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Store a cached NodeId for each of our Peers in PeerManager.

5 participants

@alecchendev@codecov-commenter@TheBlueMatt@dunxen@wpaulino
, 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Store a cached `NodeId` for each `Peer` by alecchendev · Pull Request #2022 · lightningdevkit/rust-lightning · GitHub
Skip to content

Store a cached NodeId for each Peer - #2022

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
alecchendev:2023-02-cache-peer-nodeid
Feb 8, 2023
Merged

Store a cached NodeId for each Peer#2022
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
alecchendev:2023-02-cache-peer-nodeid

Conversation

@alecchendev

@alecchendevalecchendev commented Feb 8, 2023

Copy link
Copy Markdown
Contributor

Closes#2021 as a followup on #2016.

Converts Peer field their_node_id: Option<PublicKey> to Option<(PublicKey, NodeId)> to avoid redundantly serializing peer public keys when forwarding gossip messages.

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment on lines +392 to +398
// When setting this field to a `Some(..)` value, use `Peer::set_their_node_id` to also set
// the following field `their_node_id_serialized`.
their_node_id: Option<PublicKey>,
// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
// time we forward gossip messages in `PeerManager`. It should be set anytime `their_node_id`
// gets set.
their_node_id_serialized: Option<NodeId>,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm a bit worried these could go out of sync, but doc comments which would at least appear in most author IDEs could help with that if there's no better way (which I can't think of right now). Unfortunately, single fields cannot be made externally immutable in Rust. I'm sure others might have some experience here. :)

Suggested change
// When setting this field to a `Some(..)` value, use `Peer::set_their_node_id` to also set
// the following field `their_node_id_serialized`.
their_node_id:Option<PublicKey>,
// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
// time we forward gossip messages in `PeerManager`. It should be set anytime `their_node_id`
// gets set.
their_node_id_serialized:Option<NodeId>,
/// NOTE: Do not modify this field directly. Use `Peer::set_their_node_id` instead.
their_node_id:Option<PublicKey>,
/// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
/// time we forward gossip messages in `PeerManager`.
///
/// NOTE: Do not modify this field directly. Use `Peer::set_their_node_id` instead.
their_node_id_serialized:Option<NodeId>,

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Oh oops I meant to make them doc comments, thanks. And yea those were exactly my thoughts, at the moment I can't think of a way to cache without risking them going out of sync, hoping this would have the least friction for keeping them in sync.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We could make their_node_id a tuple (PublicKey, NodeId), that way you're forced to update them in tandem.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Aha! Simple :)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Doesn't avoid the possibility of a mismatch but better than two fields.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Oh nice! Will update

@alecchendev
alecchendevforce-pushed the 2023-02-cache-peer-nodeid branch from b6b52a9 to 08e9bc3CompareFebruary 8, 2023 16:56
@codecov-commenter

codecov-commenter commented Feb 8, 2023

Copy link
Copy Markdown

Codecov Report

Base: 91.04% // Head: 91.06% // Increases project coverage by +0.02% 🎉

Coverage data is based on head (b6b52a9) compared to base (56146e7).
Patch coverage: 72.72% of modified lines in pull request are covered.

❗ Current head b6b52a9 differs from pull request most recent head 4c1055d. Consider uploading reports for the commit 4c1055d to get more accurate results

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files
@@ Coverage Diff @@## main #2022 +/- ##
==========================================
+ Coverage 91.04% 91.06% +0.02% 
==========================================
Files 99 99 Lines 51722 51727 +5 Branches 51722 51727 +5 ==========================================
+ Hits 47090 47107 +17 + Misses 4632 4620 -12 
Impacted FilesCoverage Δ
lightning/src/ln/chan_utils.rs93.57% <ø> (ø)
lightning/src/ln/peer_handler.rs55.84% <72.72%> (+0.34%)⬆️
lightning/src/util/events.rs29.56% <0.00%> (-0.24%)⬇️
lightning/src/ln/channelmanager.rs87.43% <0.00%> (+0.02%)⬆️
lightning/src/ln/functional_tests.rs97.07% <0.00%> (+0.16%)⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

This is done to avoid redundantly serializing peer node
ids when forwarding gossip messages in
`PeerManager::forward_broadcast_msg`.
@alecchendev
alecchendevforce-pushed the 2023-02-cache-peer-nodeid branch from 08e9bc3 to 4c1055dCompareFebruary 8, 2023 17:58

@dunxendunxen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This LGTM. Nice one!

@TheBlueMatt
TheBlueMatt merged commit 137b77c into lightningdevkit:mainFeb 8, 2023
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Store a cached NodeId for each of our Peers in PeerManager.

5 participants

@alecchendev@codecov-commenter@TheBlueMatt@dunxen@wpaulino
, 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); Store a cached `NodeId` for each `Peer` by alecchendev · Pull Request #2022 · lightningdevkit/rust-lightning · GitHub
Skip to content

Store a cached NodeId for each Peer - #2022

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
alecchendev:2023-02-cache-peer-nodeid
Feb 8, 2023
Merged

Store a cached NodeId for each Peer#2022
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
alecchendev:2023-02-cache-peer-nodeid

Conversation

@alecchendev

@alecchendevalecchendev commented Feb 8, 2023

Copy link
Copy Markdown
Contributor

Closes#2021 as a followup on #2016.

Converts Peer field their_node_id: Option<PublicKey> to Option<(PublicKey, NodeId)> to avoid redundantly serializing peer public keys when forwarding gossip messages.

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment on lines +392 to +398
// When setting this field to a `Some(..)` value, use `Peer::set_their_node_id` to also set
// the following field `their_node_id_serialized`.
their_node_id: Option<PublicKey>,
// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
// time we forward gossip messages in `PeerManager`. It should be set anytime `their_node_id`
// gets set.
their_node_id_serialized: Option<NodeId>,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm a bit worried these could go out of sync, but doc comments which would at least appear in most author IDEs could help with that if there's no better way (which I can't think of right now). Unfortunately, single fields cannot be made externally immutable in Rust. I'm sure others might have some experience here. :)

Suggested change
// When setting this field to a `Some(..)` value, use `Peer::set_their_node_id` to also set
// the following field `their_node_id_serialized`.
their_node_id:Option<PublicKey>,
// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
// time we forward gossip messages in `PeerManager`. It should be set anytime `their_node_id`
// gets set.
their_node_id_serialized:Option<NodeId>,
/// NOTE: Do not modify this field directly. Use `Peer::set_their_node_id` instead.
their_node_id:Option<PublicKey>,
/// This field is a cached `NodeId` of `their_node_id` to avoid serializing peers' keys every
/// time we forward gossip messages in `PeerManager`.
///
/// NOTE: Do not modify this field directly. Use `Peer::set_their_node_id` instead.
their_node_id_serialized:Option<NodeId>,

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Oh oops I meant to make them doc comments, thanks. And yea those were exactly my thoughts, at the moment I can't think of a way to cache without risking them going out of sync, hoping this would have the least friction for keeping them in sync.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We could make their_node_id a tuple (PublicKey, NodeId), that way you're forced to update them in tandem.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Aha! Simple :)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Doesn't avoid the possibility of a mismatch but better than two fields.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Oh nice! Will update

@alecchendev
alecchendevforce-pushed the 2023-02-cache-peer-nodeid branch from b6b52a9 to 08e9bc3CompareFebruary 8, 2023 16:56
@codecov-commenter

codecov-commenter commented Feb 8, 2023

Copy link
Copy Markdown

Codecov Report

Base: 91.04% // Head: 91.06% // Increases project coverage by +0.02% 🎉

Coverage data is based on head (b6b52a9) compared to base (56146e7).
Patch coverage: 72.72% of modified lines in pull request are covered.

❗ Current head b6b52a9 differs from pull request most recent head 4c1055d. Consider uploading reports for the commit 4c1055d to get more accurate results

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files
@@ Coverage Diff @@## main #2022 +/- ##
==========================================
+ Coverage 91.04% 91.06% +0.02% 
==========================================
Files 99 99 Lines 51722 51727 +5 Branches 51722 51727 +5 ==========================================
+ Hits 47090 47107 +17 + Misses 4632 4620 -12 
Impacted FilesCoverage Δ
lightning/src/ln/chan_utils.rs93.57% <ø> (ø)
lightning/src/ln/peer_handler.rs55.84% <72.72%> (+0.34%)⬆️
lightning/src/util/events.rs29.56% <0.00%> (-0.24%)⬇️
lightning/src/ln/channelmanager.rs87.43% <0.00%> (+0.02%)⬆️
lightning/src/ln/functional_tests.rs97.07% <0.00%> (+0.16%)⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

This is done to avoid redundantly serializing peer node
ids when forwarding gossip messages in
`PeerManager::forward_broadcast_msg`.
@alecchendev
alecchendevforce-pushed the 2023-02-cache-peer-nodeid branch from 08e9bc3 to 4c1055dCompareFebruary 8, 2023 17:58

@dunxendunxen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This LGTM. Nice one!

@TheBlueMatt
TheBlueMatt merged commit 137b77c into lightningdevkit:mainFeb 8, 2023
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Store a cached NodeId for each of our Peers in PeerManager.

5 participants

@alecchendev@codecov-commenter@TheBlueMatt@dunxen@wpaulino