#error-code #frame #topic #codes #protocols #ecksport #traits

ecksport-core

Defs for frame types, traits, topics, error codes, etc

6 releases

0.3.3 Aug 22, 2024
0.3.2 Aug 21, 2024
0.2.0 Aug 9, 2024
0.1.1 Aug 1, 2024

#497 in Rust patterns


Used in 3 crates

MIT license

45KB
1K SLoC

Ecksport

transport -> xport -> ecksport

Ecksport is another iteration on a low-overhead multi-use transport protocol.

This is the third iteration of this kind of idea that I've tried, so hopefully I'll get it right this time. Still have a lot to do before this is generally useable.

Design goals

Ecksport is somewhat opinionated about its design, but is not opinionated about use-cases. The core protocol is a series of frames transmitted, over which we construct a channel paradigm to multiplex independent streams. Each channel is opened in the context of a "topic" and is bidirectional by default. Each side of the connection must acknowledge a channel's closure to fully close it.

On top of this we can construct a few primitives and use them in parallel on different topics:

  • RPC call/response patterns
  • subscriptions
  • message sinks

Security

The low-level protocol does not assume an encryption system, but we have some special case messages for implementing authentication. Ecksport can be used over TLS (or anything else that can be made to transmit its frames) and can inherit its security. You could also use it in a Noise session, fitting Ecksport frames into Noise frames 1:1. It's a goal to also support transmitting frames over WebSockets, so it would be usable in a Wasm context.

Details

We use Borsh for some encoding things internally, but we intend keep it limited. Full protocol specs pending.

Uses

Ecksport is intended to be used in the Aspect messaging protocol as the typical client-server and server-server transport protocol. Make a PR to add your application that uses it!

Project structure

  • ecksport-auth - Native auth impl using NaCl-based signing key system
  • ecksport-codec - Trait def for serializable types used in the RPC server
  • ecksport-core - Defs for frame types, traits, topics, error codes, etc.
  • ecksport-net - Connection abstraction, channel handles, etc.
  • ecksport-rpc - RPC protocol definitions
  • ecksd - Server to dispatch RPC calls to subprocesses, etc. [wip]
  • eckscat - Command-line tool like netcat [wip]

Known issues

  • Horrible use of Borsh in the stream framing format. This will be fixed in the near future and replaced with an actually decent encoding, also with some utils to aid in writing framers.
  • A bunch of buffering parameters are unconfigurable, this will be exposed.
  • Insufficient feature flagging, you better want all the Tokio stuff getting built.
  • No firstparty TLS framer.

TODOs

  • Fix the Borsh thing.
  • Support both native-tls and rustls as new methods you can use on ClientBuilder, so we can use the TlsDomain identity type.
  • Clean up crate exports.
  • Make ecksd actually do what it says.
  • Maybe a blocking sync interface?

Dependencies

~5–14MB
~163K SLoC