Implement rpc server#222
Conversation
Signed-off-by: Aritra Majumder <aritramajumder8438@gmail.com>
Signed-off-by: Aritra Majumder <aritramajumder8438@gmail.com>
Signed-off-by: Aritra Majumder <aritramajumder8438@gmail.com>
Signed-off-by: Aritra Majumder <aritramajumder8438@gmail.com>
Co-authored-by: Ansh <sansh2356@gmail.com> Signed-off-by: Aritra Majumder <aritramajumder8438@gmail.com>
…zations on memory side
Signed-off-by: Aritra Majumder <aritramajumder8438@gmail.com>
Signed-off-by: Aritra Majumder <aritramajumder8438@gmail.com>
mcelrath
left a comment
mcelrath
left a comment
There was a problem hiding this comment.
The biggest problem with this PR is that the RPC cannot exist as an independent entity from the Node. It is part of the node and can't do it's job without access to the data held by the node (in particular, the Braid object).
There are a couple of ways to do this:
- Make the RPC methods be handlers on the Node object, so that they have access to all the node data (Braid, Peers, etc).
- Pass the relevant immutable object (by reference!) to the RPC object (e.g. Braid&)
Option 1 will make the Node code fairly long and un-modular, but maybe we can separate the RPC handlers in to separate files? Option 2 requires passing a lot of large objects and questions of ownership and lifetime become important.
There was a problem hiding this comment.
What we should do here is either:
- Receive a genesis bead from peers, do IBD, and decide we're "up to date".
- If we're the first node or isolated, get the tip from Bitcoind/cmempoold and use that as our genesis.
| }, | ||
| } | ||
|
|
||
| pub struct BraidManager { |
There was a problem hiding this comment.
I don't think we need a "manager" here. There will only be one braid in general, and having two will be rare (at difficulty retargets, or if we do sub-braids).
The below duplicates storage -- both the Braid class and bead_storage duplicate the storage of beads.
Instead we should put RPC handler methods in the Node class, with access to the Braid object.
| braid_manager.run().await; | ||
| }); | ||
|
|
||
| let test_bead1 = create_test_bead(1, None); // Genesis bead |
There was a problem hiding this comment.
This doesn't belong here, it should be in a test.
| } | ||
| bead::BeadResponse::Tips(tips) => { | ||
| BeadResponse::Tips(tips) => { | ||
| // Handle tips |
There was a problem hiding this comment.
For all these, call the corresponding Braid object method, and create a proper response.
| )); | ||
| } | ||
| } | ||
| "getbeadcount" => { |
There was a problem hiding this comment.
I don't understand how this is actually getting the bead count. It needs to have access to the Braid (which is owned by the Node), and call the Braid method to return the response.
| async fn get_bead(&self, bead_hash: String) -> Result<String, ErrorObjectOwned>; | ||
|
|
||
| #[method(name = "addbead")] | ||
| async fn add_bead(&self, bead_data: String) -> Result<String, ErrorObjectOwned>; |
3 participants
Please don't merge this.
This is a very primitive design for the rpc server.
It introduces a
braidmanagerclass which consists of thebraid,beads,commands.Please note that. we can remove the beads and that's our next goal. The
beadsproperty was needed when we had only thebeadhash.Below we will track a list of commands that will be exposed through the
rpcserver.gettips
getbead
getcohortcountgetcohortscountgetbeadcountgetbeadscountIf you have any more suggestions, feel free to add!