# 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.