Skip to content

Draft: Prop340: Tweak how we handle optional stream IDs again

Nick Mathewson requested to merge nickm/torspec:optional_stream_id_again into main

This comes out of work on arti#525 (closed), and of a long IRC conversation with dgoulet. It turns out that it is highly valuable (in Arti at least) to know which stream (if any) is going to receive a relay message before we decide to decode that message. That means that, if we wanted to put stream IDs in our message bodies, we would have to teach our "header parser" to peek inside the message body: that's kind of a layering violation.

Instead, we're moving the stream ID into a separate, optional header, and using the high bit of the command field to indicate whether that header is present.

Merge request reports