3 ms·

Ahh thanks for clarifying this! Makes a ton of sense now -- I need to try writing some of these style of programs (in the high perf Rust style) to see how they

Ahh thanks for clarifying this! Makes a ton of sense now -- I need to try writing some of these style of programs (in the high perf Rust style) to see how they feel. > For example, we've been considering adding a QUIC stack next to the WireGuard tunnels as a control protocol in `snownet`. By using a sans-IO QUIC implementation like quinn, I can do that entirely as an implementation detail because it just slots into the existing state machine, next to ICE & WireGuard. Have you found that this introduces a learning curve for new contributors? Being able to easily stand up another transport is pretty important, and I feel like I can whip together an async-required interface for a new protocol very easily (given I did a decent job with the required Traits and used the typestate pattern) where as sans-IO might be harder to reason about. Thanks for pointing out quinn-proto (numerous times at this point) as well -- I'll take a look at the codebase and see what I can learn from it (as well as str0m). [EDIT] > The problems of function colouring only exist if you don't focus on building the right thing: an IO-free implementation of your protocol. The protocol implementation is usually the hard bit, the one that needs to be correct and well-tested. The post, in a couple lines! [EDIT2] Any good recommendations of a tiny protocol that might be a good walk through intro to this? Something even simpler than Gopher or SMTP? Would be nice to have a really small thing to do a tiny project in.

wh33zle 2y ago
> [EDIT2] Any good recommendations of a tiny protocol that might be a good walk through intro to this? > > Something even simpler than Gopher or SMTP? Would be nice to have a really small thing to do a tiny project in. I only have experience in packet-oriented ones so I'd suggest sticking to that. Perhaps WireGuard could be simple enough? It has a handshake and timers so some complexity but nothing too crazy. DNS could be interesting too, because you may need to contact upstream resolvers if you don't have something cached.
joshka 2y ago
If you want a web protocol, try oauth2. There's complexity in the number of things you can support, but in essence there's a state machine that can be modeled.
- hardwaresofton 2y ago
  Ahh didn't even think of that level of the stack… It is true that the OAuth2 tango can be represented by a state machine… I’d probably do CAS instead, it’s simpler IMO.
  - joshka 2y ago
    The Stun protocol is surprisingly easy to implement, but see my comment at https://news.ycombinator.com/item?id=40879547 https://news.ycombinator.com/item?id=40879547 about why I'd just use async instead of making my own event loop system. https://gist.github.com/joshka/af299be87dbd1f64060e47227b5772ef https://gist.github.com/joshka/af299be87dbd1f64060e47227b577...
    - hardwaresofton 2y ago
      Thanks for the code! Going to pore over this. I read the comment and I definitely agree (though it took me a while to get to where you landed), I think there are some benefits: - More controllable/easy to reason about cancel safety (though this gets pushed up the stack somewhat). You just can't cancel a thread, but it turns out a ton of places in an async function are cancel points (everywhere you or some function calls .await, most obviuosly), and that can cause surprising problems. - Ability to easily slap on both sync and async shells (I personally think it's not unforgivable to smuggle a tokio current thread runtime in as a dep and use block_on for async things internally, since callers are none the wiser) Great comment though, very succinctly explained what I was getting at... I personally land on the "just make everything async" side of things. Not necessarily everything should be Send + Sync, but similar to Option/Result, I'd rather just start using async everywhere than try to make a sync world work. There's also libraries like agnostic[0] that make it somewhat easier to support multiple runtimes (though I've done it in the past with feature flags). > The problem with the approach suggested in the article is that it splits the flow (event loop) and logic (statemachine) from places where the flow is the logic (send a stun binding request, get an answer). Very concisely put -- If I'm understanding OP's point of view, the answer to this might be "don't make the flow the logic"? basically rather encoding the flow as a state machine and passing that up to an upper event loop (essentially requiring the upper layer to do it). Feels like there are at least 3 points in this design space: - Sync only state machines (event loop must be at the outermost layer) - Sync state machines with possibly internal async (event loops could be anywhere) - Async everything (event loops are everywhere) [0]: https://crates.io/crates/agnostic https://crates.io/crates/agnostic

wh33zle 2y ago

> [EDIT2] Any good recommendations of a tiny protocol that might be a good walk through intro to this? > > Something even simpler than Gopher or SMTP? Would be nice to have a really small thing to do a tiny project in. I only have experience in packet-oriented ones so I'd suggest sticking to that. Perhaps WireGuard could be simple enough? It has a handshake and timers so some complexity but nothing too crazy. DNS could be interesting too, because you may need to contact upstream resolvers if you don't have something cached.

joshka 2y ago

If you want a web protocol, try oauth2. There's complexity in the number of things you can support, but in essence there's a state machine that can be modeled.

hardwaresofton 2y ago
Ahh didn't even think of that level of the stack… It is true that the OAuth2 tango can be represented by a state machine… I’d probably do CAS instead, it’s simpler IMO.
- joshka 2y ago
  The Stun protocol is surprisingly easy to implement, but see my comment at https://news.ycombinator.com/item?id=40879547 https://news.ycombinator.com/item?id=40879547 about why I'd just use async instead of making my own event loop system. https://gist.github.com/joshka/af299be87dbd1f64060e47227b5772ef https://gist.github.com/joshka/af299be87dbd1f64060e47227b577...
  - hardwaresofton 2y ago
    Thanks for the code! Going to pore over this. I read the comment and I definitely agree (though it took me a while to get to where you landed), I think there are some benefits: - More controllable/easy to reason about cancel safety (though this gets pushed up the stack somewhat). You just can't cancel a thread, but it turns out a ton of places in an async function are cancel points (everywhere you or some function calls .await, most obviuosly), and that can cause surprising problems. - Ability to easily slap on both sync and async shells (I personally think it's not unforgivable to smuggle a tokio current thread runtime in as a dep and use block_on for async things internally, since callers are none the wiser) Great comment though, very succinctly explained what I was getting at... I personally land on the "just make everything async" side of things. Not necessarily everything should be Send + Sync, but similar to Option/Result, I'd rather just start using async everywhere than try to make a sync world work. There's also libraries like agnostic[0] that make it somewhat easier to support multiple runtimes (though I've done it in the past with feature flags). > The problem with the approach suggested in the article is that it splits the flow (event loop) and logic (statemachine) from places where the flow is the logic (send a stun binding request, get an answer). Very concisely put -- If I'm understanding OP's point of view, the answer to this might be "don't make the flow the logic"? basically rather encoding the flow as a state machine and passing that up to an upper event loop (essentially requiring the upper layer to do it). Feels like there are at least 3 points in this design space: - Sync only state machines (event loop must be at the outermost layer) - Sync state machines with possibly internal async (event loops could be anywhere) - Async everything (event loops are everywhere) [0]: https://crates.io/crates/agnostic https://crates.io/crates/agnostic