[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #1298 [Tor Client]: Tor does not treat multiple streams fairly

#1298: Tor does not treat multiple streams fairly
-------------------------+--------------------------------------------------
  Reporter:  mikeperry   |       Owner:  nickm             
      Type:  defect      |      Status:  assigned          
  Priority:  major       |   Milestone:  Tor: 0.2.2.x-final
 Component:  Tor Client  |     Version:  0.2.1.24          
Resolution:  None        |    Keywords:                    
    Parent:              |  
-------------------------+--------------------------------------------------

Comment(by nickm):

 Grepping: We call connection_edge_package_raw_inbuf() in 4 places.  One is
 the case in relay.c that we fixed in #1937.  The other three cases have no
 constraint on how much we process from the stream.  They are:

  * In relay.c:
    * (A) connection_edge_process_relay_cell_not_open(), upon receiving a
 RELAY_COMMAND_CONNECTED
    * (B) connection_edge_process_relay_cell(), upon receiving a
 RELAY_COMMAND_SENDME.
    * (C) The case in relay.c that we fixed with #1937
  * In connection_edge.c
    * (D) connection_edge_process_inbuf(), upon receiving data on an edge
 connection.

 Case (C) is fixed.  Case (D) is fair, since we'll just package data as it
 arrives, and we consider connections that we can read from in pseuodrandom
 or first-come-first-served order.

 Case (A) and case (B) can lead to hogging the circuit temporarily, though
 I think it happens in a more-or-less fair way.  It would be neat to make
 those cases less hoggish, but we have a bit of an architectural problem in
 the way.  Right now (as you can see above) there are two circumstances
 when we package edge data into relay cells:
   * (1) Data arrives on an edge conn, so we package as much as we can
 immediately.
   * (2) An edge-conn becomes non-blocked (either it was blocked on its
 own, or its whole circuit was blocked), so we package as much data as we
 can (from the connection if just one was blocked, or from all the
 connections on a circuit if a whole circuit was blocked).

 Thus, if we leave data on an edge conn inbuf temporarily without blocking
 the edge conn, there's currently no mechanism to make sure that it will
 get pulled off unless more data arrives, or unless the edge conn becomes
 blocked then unblocked.

 We could add such a mechanism, I guess, but I'm not currently clear on how
 it would look.  I think it can wait for 0.2.3.x, though?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1298#comment:24>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs