rippled
rippled copied to clipboard
XRPLF
Add MessageScheduler
High Level Overview of Change
This is a second version of a message scheduler (formerly called peer scheduler). There is a long Markdown document walking through the motivation, intuition, interface, and a few important design points. Please take a look, ask questions (it will help me know what to include in the document and how to explain it), and poke holes (it will improve the design and implementation).
Context of Change
I wanted to make it easy for different components to send the same types of messages, to all connected peers, while dispatching responses to the corresponding different receivers, and hiding the concerns of balancing message priority or rate limiting traffic.
This is a radical revision of the changeset in PR #4199. I chose to create a new PR because of the magnitude of the difference. I'll be working through the comments in that PR, but want to move all new discussion here.
Type of Change
- [x] New feature (non-breaking change which adds functionality)
There is a compilation error with boost 1.71.0. (Boost versions 1.71.0 to 1.77.0 are currently supported as https://xrpl.org/build-run-rippled-ubuntu.html)
boost/system/detail/error_code.hpp: No such file
notes: doesn't really affect anything; adds some code that is unused at the moment. putting this up so that people can talk about the design and implementation, and critique it. however, this is in a good spot, and can be merged (after addressing above comments).
Reviewers: Please start with reading the document - https://github.com/XRPLF/rippled/blob/4ab195b1d766410b6f8be79ba3c716cb3110afc0/src/ripple/overlay/MessageScheduler.md
I'm getting a unittest failure:
rippled --unittest
ripple.tx.Offer Removing Canceled Offers
Assertion failed: (max > min), function rand_int, file /Users/howardhinnant/Development/rippled/src/ripple/basics/random.h, line 117.
Abort trap: 6
I've lost the ability to compile this PR. I recommend it be updated to the conan build system.
@HowardHinnant, I had the same problem. I was able to compile (pre-conan-style) If I cherry-picked the following two commits on top of this pull request:
- 5d38e4cfbfe457999f942ba09bff789e06bb81f9
- f5af42a64089ab0563c343a9eba234627d8afe5e
@thejohnfreeman, unfortunately the "See #4217 (comment)" links are not leading me to a reliable place. So I can't figure out what it is you're trying to say with those links. Often one link takes me to another link. In some situations following those links eventually takes me in a loop.
So I'm unsure what you're trying to communicate with the links. Sorry.
@scottschurr
- if I search the page for an example, I land here in unresolved thread A: https://github.com/XRPLF/rippled/pull/4217#discussion_r1171576072
- that comment contains a link to here in resolved thread B: https://github.com/XRPLF/rippled/pull/4217#discussion_r1134488074
- that comment is yours, about calling foreign code while holding a lock, which is the same topic of discussion in thread A. below that comment, still in thread B, is this comment from me: https://github.com/XRPLF/rippled/pull/4217#discussion_r1171575351
- that comment links back to thread A, to the meatiest comment at the start of thread A, this one written by you: https://github.com/XRPLF/rippled/pull/4217#discussion_r1146658592
all the links I posted should follow that pattern. my comment in unresolved thread A says "see this comment in thread B (link)". thread B is resolved, and at the end is a comment from me saying "resolving this thread to consolidate discussion in thread A (link)".
it's possible I made a mistake in one or more of these bidirectional links. please share any examples you find.
@thejohnfreeman, thanks for the explanation of how the links are intended to work. I was not paying enough attention to which comments were marked as resolved. I now understand the intent.