nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-10 21:23:58 +01:00
Code Issues Packages Projects Releases Wiki Activity

Clarify that TRUNCATE behavior isn't as-intended

Browse Source 
In tor-spec.txt, instead of saying "nodes may X" instead say "Current
nodes do X; this is nonconformant. Clients should watch out for that."

Based on observations by wanoskarnet.
This commit is contained in:
Nick Mathewson 2010-08-02 12:28:25 -04:00
parent 6f45101327
commit c4b83b2177
1 changed files with 9 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/spec/tor-spec.txt
View File

@ -595,9 +595,15 @@ see tor-design.pdf.
To tear down part of a circuit, the OP may send a RELAY_TRUNCATE cell
signaling a given OR (Stream ID zero). That OR sends a DESTROY
cell to the next node in the circuit, and replies to the OP with a
RELAY_TRUNCATED cell. If the OR has any RELAY cells queued on the
circuit for the next node in that it had not yet sent, it MAY
drop them without sending them.
RELAY_TRUNCATED cell.
[Note: If an OR receives a TRUNCATE cell and it any RELAY cells queued on
the circuit for the next node in that it had not yet sent, it will drop
them without sending them. This is not considered conformant behavior,
but it probably won't get fixed till a later versions of Tor. Thus,
clients SHOULD NOT send a TRUNCATE cell to a node running any current
version of Tor if they have sent relay cells through that node, and they
aren't sure whether those cells have been sent on.]
When an unrecoverable error occurs along one connection in a
circuit, the nodes on either side of the connection should, if they