Uh oh!
There was an error while loading. Please reload this page.
Expose onion messages in public API - #1650
Conversation
848a6d9 to
d93d568CompareUh oh!
There was an error while loading. Please reload this page.
4e8e973 to
3209ac5CompareUh oh!
There was an error while loading. Please reload this page.
3209ac5 to
6b01547Compare6b01547 to
ee37e44Comparevalentinewallace
commented
Aug 26, 2022
Now based on #1604 |
TheBlueMatt
commented
Aug 29, 2022
Needs rebase. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
ee37e44 to
664f139CompareCodecov Report
@@ Coverage Diff @@## main #1650 +/- ##
==========================================
+ Coverage 90.85% 90.98% +0.13%
==========================================
Files 85 85 Lines 45948 46681 +733 Branches 45948 46681 +733 ==========================================
+ Hits 41746 42474 +728 - Misses 4202 4207 +5
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
664f139 to
ec1af89Compareec1af89 to
366662eComparevalentinewallace
commented
Aug 31, 2022
@TheBlueMatt should we only be connecting peers to |
TheBlueMatt
commented
Sep 1, 2022
We should consider some kind of only-channel-peers thing in the future, I think, but just as a way to give those peers larger buffers and give other peers almost no buffer space. That said, we need to limit the buffer in Picking a random number for the buffer limit, let's go with 256KiB for now. Default open files limit on my local machine in front of me is 1024, which means we'd max out at 256MiB in buffer size. |
366662e to
0ed9416CompareTheBlueMatt
commented
Sep 1, 2022
Looks like the fuzzing seeds need updating. |
0ed9416 to
abf3517CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
5251618 to
3a4a6ebCompareUh oh!
There was an error while loading. Please reload this page.
3a4a6eb to
447ba29CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| let mut peer_buffered_bytes = 0; | ||
| for (pk, peer_buf) in buffer { | ||
| for om in peer_buf { | ||
| let om_len = om.serialized_length(); |
There was a problem hiding this comment.
Could we optimize this by implmenting serialized_length on OnionMessage and Packet? Seems a bit wasteful to serialize all pending messages any time an onion message is sent.
There was a problem hiding this comment.
I'd put good money on it being free. In the past I've investigated this for a few things and LLVM is pretty good at dealing with the simple cases. As the comment for serialized_length says "Note that LLVM optimizes this away in most cases! Check that it isn't before you override!"
There was a problem hiding this comment.
Ah, right. Was just looking at the implementation and noticed that comment. Feel free to disregard!
And fix warnings
We also refuse to connect to peers that don't advertise onion message forwarding support.
447ba29 to
235f4a5CompareDrop OMs if they push us over the max OnionMessenger outbound buffer size
235f4a5 to
a8ea0bdCompare
This completes the final anti-DoS steps needed for us to be able to make the onion messages API public and integrate the
OnionMessengerwith thePeerManager. See commit messages for more info.TODO: add tests for the last commit after it's conceptually ACK'd
Blocked on #1604 and #1648