https://github.com/casper-network/juliet
A TCP-based, multiplexing, backpressuring low-overhead transport protocol.
https://github.com/casper-network/juliet
Last synced: 8 months ago
JSON representation
A TCP-based, multiplexing, backpressuring low-overhead transport protocol.
- Host: GitHub
- URL: https://github.com/casper-network/juliet
- Owner: casper-network
- License: apache-2.0
- Created: 2023-11-16T14:40:59.000Z (over 2 years ago)
- Default Branch: main
- Last Pushed: 2024-03-14T12:31:27.000Z (about 2 years ago)
- Last Synced: 2024-12-29T13:35:55.732Z (over 1 year ago)
- Language: Rust
- Homepage:
- Size: 545 KB
- Stars: 9
- Watchers: 6
- Forks: 11
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE
Awesome Lists containing this project
README
# Juliet protocol implementation
This crate implements the Juliet multiplexing protocol version 1.0.1 as laid out in the [Juliet RFC](https://github.com/casper-network/juliet/blob/rfc-1.0.1/RFC.md). It aims to be a secure, simple, easy to verify/review implementation that is still reasonably performant.
## Benefits
The Juliet protocol comes with a core set of features, such as
* carefully designed with security and DoS resilience as its foremoast goal,
* customizable frame sizes,
* up to 256 multiplexed, interleaved channels,
* backpressure support fully baked in, and
* low overhead (4 bytes per frame + 1-5 bytes depending on payload length).
This crate's implementation includes benefits such as
* a side-effect-free implementation of the Juliet protocol,
* an `async` IO layer integrated with the [`bytes`](https://docs.rs/bytes) crate to use it, and
* a type-safe RPC layer built on top.
## Examples
For a quick usage example, see `examples/fizzbuzz.rs`.
## `tracing` support
The crate has an optional dependency on the [`tracing`](https://docs.rs/tracing) crate, which, if enabled, allows detailed insights through logs. If the feature is not enabled, no log statements are compiled in.
Log levels in general are used as follows:
* `ERROR` and `WARN`: Actual issues that are not protocol level errors -- peer errors are expected and do not warrant a `WARN` level.
* `INFO`: Insights into received high level events (e.g. connection, disconnection, etc), except information concerning individual requests/messages.
* `DEBUG`: Detailed insights down to the level of individual requests, but not frames. A multi-megabyte single message transmission will NOT clog the logs.
* `TRACE`: Like `DEBUG`, but also including frame and wire-level information, as well as local functions being called.
At `INFO`, it is thus conceivable for a peer to maliciously spam local logs, although with some effort if connection attempts are rate limited. At `DEBUG` or lower, this becomes trivial.