8000 abci: Next-generation remote application network protocol · Issue #1117 · cometbft/cometbft · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

abci: Next-generation remote application network protocol #1117

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.

Sign up for GitHub

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

Jump to bottom
Open
thanethomson opened this issue Jul 12, 2023 · 1 comment
Open

abci: Next-generation remote application network protocol #1117

thanethomson opened this issue Jul 12, 2023 · 1 comment
Labels
abci Application blockchain interface enhancement New feature or request P:new-use-cases Priority: Enable new use cases for application developers

Comments

@thanethomson
Copy link
Contributor
thanethomson commented Jul 12, 2023 •
edited
Loading

Relates to #88, and to enable bidirectional requests as per #1112 and #494 in future, the network protocol between remote applications and Comet needs to be reconsidered. The requirements for the future ABCI remote protocol are as follows (will be updated based on feedback on this issue).

The network interaction between a remote application instance and Comet must:

  1. Be full-duplex.
  2. Offer comparable reliability to TCP.
  3. Offer message prioritization whereby messages of higher priority are not (or minimally) blocked by messages of lower priority.
  4. Facilitate bidirectional request initiation (i.e. the application must be able to initiate certain requests where Comet responds, and Comet must be able to initiate other requests where the application responds).

Nice-to-haves:

  1. Generation of clients and servers should be very easy to support ABCI applications built in any programming language.

The protocol candidates currently under consideration are summarized in the following table.

Candidate Full-duplex Reliable transport Prioritization Bidirectional requests Easy client/server generation
Tendermint Socket Protocol (TSP) ✔️ ✔️ ✅ 1 ❌ ❌
gRPC ✔️ ✔️ ❓ 2 ✅ 3 ✔️
QUIC4 ✔️ ✔️ 5 ✔️ ✔️ ❌
❓

1 TSP effectively supports a weak form of prioritization through forcing the use of different TCP connections for different types of traffic. It still does not facilitate per-connection prioritization as prioritized framing/chunking of messages would.

2 The degree to which we can influence the lower-level HTTP/2 framing and stream prioritization in gRPC communications is unclear.

3 Bidirectional gRPC interactions are only either possible through gRPC streaming, which is not really recommended due to potential stability issues, or by way of implementing clients and servers on both the application and Comet, which results in greater configuration and/or initial handshake complexity.

4 One unknown regarding QUIC is whether it's possible to detect a "disconnection", since QUIC builds on top of UDP.

5 Assumes interaction on a network where UDP traffic can flow largely unhindered.
@thanethomson thanethomson added enhancement New feature or request abci Application blockchain interface P:new-use-cases Priority: Enable new use cases for application developers labels Jul 12, 2023
@thanethomson
Copy link
Contributor Author

Another option to consider here is WebTransport.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
abci Application blockchain interface enhancement New feature or request P:new-use-cases Priority: Enable new use cases for application developers
Projects
No open projects
CometBFT 2023
Status: Todo
Milestone
No milestone
Development

No branches or pull requests
1 participant
@thanethomson
0