Re: [tor-dev] Proposal 325: Packed relay cells: saving space on small commands
On Fri, Jul 10, 2020 at 2:07 PM Ian Goldberg 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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 325: Packed relay cells: saving space on small commands
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" > 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.) > 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"? -- Ian Goldberg Canada Research Chair in Privacy Enhancing Technologies Professor, Cheriton School of Computer Science University of Waterloo ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev