Skip to content

Client-side backend code for UDP support

@dgoulet is interested in writing a client-side backend code to allow programmatic access to the UDP-over-tor protocol as specified in proposal 339.

Here are, roughly, the steps you'd need:

  • We need to be able to send and receive the new messages. Add parsing and encoding support for the new relay message types in tor-cell::relay::msg.
  • We need to be able to tell which exits support UDP. Add parsing support for the new exit policy types for microdescriptors in tor-netdoc::doc::microdesc.
  • Here's the core: we need a type corresponding to a datagram stream, that can send and receive UDP messags. Add new DatagramStream type for UDP messages in tor-proto. They should re-use tor_proto::stream::raw::{StreamReader,StreamWriter} under the hood. Probably they should share code with tor_proto::stream::data; it would be good to avoid code duplication when possible.
  • We'll need a way to create these streams! Make a new function like begin_data_stream on tor_proto::ClientCirc to begin a datagram stream.
  • The circuit manager will need to know how to tell which exits it can use for UDP. Add a new variants or new fields in tor_circmgr::usage::{TargetCircUsage,SupportedCircUsage} to handle requesting a circuit whose exit needs to support UDP. Maybe the right way to do this is by adding a new boolean and a new set of constructors to TargetPort?
  • We'll need a way to make these streams correctly from arti_client. That might take the form of a new connect_udp and connect_udp_with_prefs function pair, similar to the existing connect and connect_with_prefs in TorClient. We'll want to avoid code duplication with those functions.

General notes:

  • At every point we should keep test coverage as high as we can!
  • The new UDP functions in high-level crates should probably be #[cfg(feature="experimental-api)] for now.
  • It's probably a good idea to do a separate MR for each stage listed above.
  • If any of the existing code doesn't make sense, just ask! It's probably badly documented or badly explained, and we should fix that.
Edited by David Goulet