Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

book/architecture: RPC handlers and related #341

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions SCRATCHPAD.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
RPC stuff that needs to be written in the architecture book:

## General
- diagram showing full pipeline from input to output with crate responsibilities listed along the line

## The handler
- {json-rpc, binary, other} handler functions implemented in `cuprated` <CODE_LINK>
- handler -> helper function -> internal component's `Service`

## Unsupported RPC calls / RPC calls with different behavior
- https://github.com/Cuprate/cuprate/issues/278
- binary strings -> full JSON: `get_transaction_pool_backlog`, `get_output_distribution`
- not in `monerod` yet: `get_tx_ids_loose`

## Differences with monerod (Request strictness)
Some of `monerod`'s RPC request types contain fields not for users to provide,
but for internal usage within the RPC handlers and `monerod` itself, some examples:
- <LINK_TO_INTERNAL_FIELDS_IN_REQUEST_TYPE>

Unless one of these actually allows something unintentionally bad to happen, this is mostly an unimportant detail.
<CHECK_THAT_ONE_OF_THESE_FIELDS_ISNT_A_SECURITY_FLAW>

Practically, it means users can provide these fields and `monerod` will deserialize them
and accept them fine, while `cuprated` will not because they are not part of the type.
Loading