[tor-bugs] #1784 [Tor Relay]: RELAY_TRUNCATE should give cell queues a chance to flush

[Tor Bug Tracker & Wiki]

#1784: RELAY_TRUNCATE should give cell queues a chance to flush
-----------------------+----------------------------------------------------
 Reporter:  nickm      |       Owner:     
     Type:  defect     |      Status:  new
 Priority:  normal     |   Milestone:     
Component:  Tor Relay  |     Version:     
 Keywords:             |      Parent:     
-----------------------+----------------------------------------------------

Comment(by arma):

 Yeah, this one's definitely a mess.

 Another simpler option would be to just move all the queued cells onto the
 n_conn buffer before queuing the outgoing destroy cell for that circuit.
 Not exactly polite or fair, but it would restore correctness.

 My main hesitation about that plan is that it opens a way for clients to
 be unfair.

 I need to remember more about the actual protocol here though. If relay X
 gets a truncate request, it sends a destroy cell to relay X+1, which
 {{{
   if (!CIRCUIT_IS_ORIGIN(circ) &&
       cell->circ_id == TO_OR_CIRCUIT(circ)->p_circ_id) {
     /* the destroy came from behind */
     circuit_set_p_circid_orconn(TO_OR_CIRCUIT(circ), 0, NULL);
     circuit_mark_for_close(circ, reason|END_CIRC_REASON_FLAG_REMOTE);
   }
 }}}
 which ends up calling such lines as
 {{{
     for (conn=or_circ->n_streams; conn; conn=conn->next_stream)
       connection_edge_destroy(or_circ->p_circ_id, conn);
     or_circ->n_streams = NULL;
 }}}

 So is it the case right now that an outgoing destroy cell will blow away
 things in the n cell queue, and an outgoing truncate cell also will, and
 we're thinking about fixing the latter while leaving the former alone?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1784#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online