Accept connections

[efimio16]

Add "accept-connections" feature to the emittio network crate to listen for incoming connections on a specific port and to have a static key for 0-RTT sessions

[mikeyoung3k]

Believe this is the Receive/Connection bottom right corner of the flow diagram at https://github.com/efimio16/Emittio/blob/main/crates/emittio-network/docs/ARCHITECTURE.md

[mikeyoung3k]

Also assuming that this isn't a feature in the Rust/cargo sense of a feature, but a requirement for core Emittio

[mikeyoung3k]

Quite a lot has changed since I was last here! Looks like NetworkActor is going to be managing secrets for each session.
The actor is a service running in the background, and I think it should have a manager for connections (as opposed to being one).

I think that it should take that manager via a trait to allow different connection types (TCP, WebSocket, etc) which will yield messages and allow sending to a ConnId.

NetworkActor can convert between ConnId and PeerId as necessary.

Drafting a Transport trait to do this.

[mikeyoung3k]

Making the trait handle 0-RTT establishment is interesting.

Given we expect a 1-RTT handshake to be completed in the next transmission, the trait could just return the handshake data directly. Thus any call to establish a connection via the trait must upgrade to a 1-RTT in that call.

OTOH, maybe you just fire and forget the 0-RTT data and handshake, and listen for the returning handshake like normal. If you did that you could continuously fire off 0-RTT messages without upgrading to 1-RTT which feels like a bad idea.

Possible that actually it's time for some type state with a Connection type with states (otherwise named) 0-RTT and 1-RTT and you can only send data to a 1-RTT variant (the initial establishment returning a 0-RTT type which needs to be upgraded...

[mikeyoung3k]

*3 states to include closed

[efimio16]

Believe this is the Receive/Connection bottom right corner of the flow diagram at https://github.com/efimio16/Emittio/blob/main/crates/emittio-network/docs/ARCHITECTURE.md

Yes it is

Also assuming that this isn't a feature in the Rust/cargo sense of a feature, but a requirement for core Emittio

In fact I think it should be a cargo feature because when we will build binaries for emittio client (CLI/maybe TUI/GUI/Web/Mobile), it doesn’t need to accept connections or have any methods/structure fields (like static key) related to that. Only nodes will do that. Also we cannot import tokio::net in a web environment, so we definitely need cargo features.

Quite a lot has changed since I was last here! Looks like NetworkActor is going to be managing secrets for each session. The actor is a service running in the background, and I think it should have a manager for connections (as opposed to being one).

I think that it should take that manager via a trait to allow different connection types (TCP, WebSocket, etc) which will yield messages and allow sending to a ConnId.

NetworkActor can convert between ConnId and PeerId as necessary.

Drafting a Transport trait to do this.

Good idea with the Transport trait!

Making the trait handle 0-RTT establishment is interesting.

Given we expect a 1-RTT handshake to be completed in the next transmission, the trait could just return the handshake data directly. Thus any call to establish a connection via the trait must upgrade to a 1-RTT in that call.

OTOH, maybe you just fire and forget the 0-RTT data and handshake, and listen for the returning handshake like normal. If you did that you could continuously fire off 0-RTT messages without upgrading to 1-RTT which feels like a bad idea.

Possible that actually it's time for some type state with a Connection type with states (otherwise named) 0-RTT and 1-RTT and you can only send data to a 1-RTT variant (the initial establishment returning a 0-RTT type which needs to be upgraded...

If you are talking about the Transport trait, I think it should just have methods to spawn and listen connections, not to handle cryptographic sessions and handshakes.

Interesting idea about an unified Connection state, but later we’ll need to clear sessions and states and their TTL will vary depending on whether the session/state is 0- or 1-RTT (I’ll create an issue for that). Because of that, I think it’s better to keep them in separated HashMaps.

[efimio16]

I take back what I said about Connection state and multiple HashMaps: I see now there is a way to have different TTLs in a one HashMap (just save the timestamp when it needs to be cleared, not the TTL itself). So if you want you can design that and/or open a new issue!