[tor-dev] Proposal 325: Packed relay cells: saving space on small commands

Nick Mathewson nickm at freehaven.net
Fri Jul 10 19:16:09 UTC 2020


On Fri, Jul 10, 2020 at 2:07 PM Ian Goldberg <iang at uwaterloo.ca> wrote:
>
> On Fri, Jul 10, 2020 at 01:52:00PM -0400, Nick Mathewson wrote:
> > After receiving a packed relay cell, the relay know that the client
>
> typo: "know" -> "knows"

thanks!

> >     struct relay_header {
> >        u1 stream_id_included; // Is the stream_id included?
> >        u6 relay_command; // as before
> >        u9 relay_data_len; // as before
> >        u8 optional_stream_id[]; // 0 bytes or two bytes.
> >     }
> >
> > Alternatively, you can view the first three fields as a 16-bit
> > value, computed as:
> >
> >     (stream_id_included<<15) | (relay_command << 9) | (relay_data_len).
>
> Where everything is big-endian, both at the byte and bit level?  (Is
> that specified at some higher level in the specs?  I forget.)

Early in the spec, we say that we always use network byte order. I
don't think we ever actually spec a bit order.

> > If the optional_stream_id field is not present, then the default
> > value for the stream_id is computed as follows.  We use stream_id 0
> > for any command that doesn't take a stream ID.  For commands that
> > _do_ take a steam_id, we use whichever nonzero stream_id appeared
> > last in this cell.
>
> Do you mean "last in this cell" as in "the one closest to the end of the
> cell" or as in "the one that appeared closest to, but before, this relay
> command header"?

Ah; the latter. Maybe "most recently" would be more clear?

yrs,
-- 
Nick


More information about the tor-dev mailing list