Implement client part of prop340: packed and fragmented relay messages
Draft implementation plan:
-
Finish ntorv3 (prop332). #1084 (closed) -
Implement negotiation for prop340 itself. EDIT: spec for negotiation may be in flux, since current version in prop340 doesn't align with prop346; see torspec!170 (merged). (Q: maybe also behind an "experimental" compile-time feature?) -
add new consensus and config parameter "UseRelayMessage", as specified in prop340 -
add new subprotocol variant "RelayCell" -
add new ntorv3 extension types 3 and 4 "Relay Cell Protocol Request" and "Response" -
when enabled, and creating a circuit with a relay supporting ntorv3 ( Relay=4
) and the new cell format (RelayCell=1
) (Q: or select only such relays?), request version 1 of in ntorv3 "Relay Cell Protocol Request" -
when enabled, and relay has advertised support, switch to prop340 cell format. (initially log an "unimplemented" error just to verify we get this far in integration testing and destroy the circuit)
-
-
Implement the prop340 new cell format. (e.g. omitting stream ID instead of setting it to 0 etc) -
Refactor StreamId
to always be nonzero, replacing usage withOption<StreamId>
. #1080 (closed)
-
-
Refactor to decouple cells from messages (Prepare tor-cell API for proposal 340 (#763) and Rectify names in tor-proto and tor-cell for pro... (#775 - closed)) -
Implement packing -
Implement fragmentation
Edited by Jim Newsome