14 releases
0.2.0 | Sep 21, 2020 |
---|---|
0.1.0 | Sep 12, 2020 |
0.0.12 | Sep 6, 2020 |
0.0.9 | Aug 22, 2020 |
#3 in #coordinator
265KB
5.5K
SLoC
conec: COordinated NEtwork Channels
high-level description
-
A coordinated network channels instance comprises one Coordinator and one or more Clients.
Clients know (by configuration) the identity of Coordinator (say, a hostname for which Coordinator has a TLS server cert).
Clients authenticate to Coordinator with a TLS certificate. By default, clients generate ephemeral self-signed certificates; they can also be configured to use long-lived certs signed by a CA that Coordinator trusts.
-
The basic abstraction is a channel, which connects two entities (Client or Coordinator). A channel comprises one bi-directional control stream and zero or more bidirectional data streams (streams defined below).
Every Client shares a channel with Coordinator: at startup, Client connects to Coordinator.
Clients can ask Coordinator to help them open a channel to another Client. By default, Clients will attempt to use holepunching for NAT traversal; this ought to work except when the Client receiving the connection is behind a symmetric NAT. Please post an issue on the GitHub repo if this doesn't work for you!
-
A data stream accepts a sequence of (known length) messages from its writer. The data stream's reader receives these messages in order. The stream handles all message framing: a read yields a full message or nothing. No support for out-of-order reads; use multiple data streams instead.
-
Control streams are used internally to manage the connection. The user code does not interact with them except via the API (e.g., in most cases opening a data stream entails sending and receiving messages on a control stream).
TODOs / functionality / future features / maybes
- basic functionality
- per-channel driver @ Coord
- Client connection: switch handshake order, detect dup-id earlier
- proxied streams through coordinator
- features and improvements
- for Client futures:
map(|x| x.map_err(FooError))
to get rid of multiple unwraps - Client authentication via pubkeys
-
direct Client <-> Coord streams- v0.0.12 removes these --- just use a new Client with a well-known name!
- this ends up being a considerable simplification
- v0.0.12 removes these --- just use a new Client with a well-known name!
- Client keepalive
- direct Client <-> Client channels
- incoming channels listener
- client-to-client channels impl
- hold channels in ichan
- send ichan event to open new channel
- send ichan event to open new stream
- who owns Endpoint? Clone in ichan? ((( Option<> in Client? )))
- allow Client to connect even though it is not listening
- allow Client to close a channel to another client
- seems like there is a bug somewhere---quinn? rustls?---that close/reopen triggers
- investigate this bug!
- broadcast streams for Clients
-
broadcast streams for Coordinator?- no: just connect a Client
- v0.0.12 removed Coordinator-side stream support
- Broadcast: identify the sending client?
- add intf to automagically pick between client-to-client and proxied streams
- Allow Coord to require trusted CA for client certs
- in this case, coord will forward trust root for client-to-client
- NAT traversal
- holepunching works in my one-off tests. Can we test automatically?
- more
tracing
- carefully recheck drop notifications for critical pieces of Coord/Chan
- for Client futures:
- questions / maybes
- Client driver - what is the API for this? one driver for whole client?
- better Client naming (name by pubkey? but only if not ephemeral...)
- no. eventually, can enforce naming policy by using client cert CA at coord
- Client <-> Coord streams? (decision: yes)
- switch ControlMsg -> CoCtrlMsg and ClCtrlMsg? (decision: no)
- switch from String to Bytes where possible to reduce copying?
- decision: no: atomics are potentially worse than copies for <= 1kB
- error handling
- eliminate
anyhow
in favor of unboxed Error types - create ConecError type to give better error msgs
- switch to ConecError
- eliminate
license
Copyright 2020 Riad S. Wahby
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
Dependencies
~18–28MB
~516K SLoC