diff options
Diffstat (limited to 'proposals/325-packed-relay-cells.md')
| -rw-r--r-- | proposals/325-packed-relay-cells.md | 60 |
1 files changed, 36 insertions, 24 deletions
diff --git a/proposals/325-packed-relay-cells.md b/proposals/325-packed-relay-cells.md index 6498d4c..7d0ffca 100644 --- a/proposals/325-packed-relay-cells.md +++ b/proposals/325-packed-relay-cells.md @@ -3,9 +3,11 @@ Filename: 325-packed-relay-cells.md Title: Packed relay cells: saving space on small commands Author: Nick Mathewson Created: 10 July 2020 -Status: Open +Status: Obsolete ``` +(Proposal superseded by proposal 340) + # Introduction In proposal 319 I suggested a way to fragment long commands across @@ -55,23 +57,27 @@ concatenated one after another following this format of a relay cell. The first command is the same header format as a normal relay cell detailed in section 6.1 of tor-spec.txt - Relay Command [1 byte] - 'Recognized' [2 bytes] - StreamID [2 bytes] - Digest [4 bytes] - Length [2 bytes] - Data [Length bytes] - RELAY\_MESSAGE - Padding [up to end of cell] +```text +Relay Command [1 byte] +'Recognized' [2 bytes] +StreamID [2 bytes] +Digest [4 bytes] +Length [2 bytes] +Data [Length bytes] +RELAY\_MESSAGE +Padding [up to end of cell] +``` The `RELAY_MESSAGE` can be empty as in no bytes indicating no other messages or set to the following: - Relay Command [1 byte] - StreamID [2 bytes] - Length [2 bytes] - Data [Length bytes] - RELAY\_MESSAGE +```text +Relay Command [1 byte] +StreamID [2 bytes] +Length [2 bytes] +Data [Length bytes] +RELAY\_MESSAGE +``` Note that the Recognized and Digest field are not added to a second relay message, they are solely used for the whole relay cell thus how we @@ -121,10 +127,12 @@ with the default set to use a consensus parameter. The parameter is: - "relay-cell-packing" +```text +"relay-cell-packing" - Boolean: if 1, clients should send packed relay cells. - (Min: 0, Max 1, Default: 0) +Boolean: if 1, clients should send packed relay cells. +(Min: 0, Max 1, Default: 0) +``` To handle migration, first the parameter should be set to 0 and the configuration setting should be "auto". To test the feature, individual @@ -148,17 +156,21 @@ I propose a new relay message format, described here (with `ux` denoting an x-bit bitfield). This format is 2 bytes or 4 bytes, depending on its first bit. - 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. - } +```C +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). +```C +(stream_id_included<<15) | (relay_command << 9) | (relay_data_len). +``` 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 |