[tor-bugs] #12890 [Tor]: Design and implement optimizations for socket write limits

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Dec 23 17:32:00 UTC 2014


#12890: Design and implement optimizations for socket write limits
-----------------------------+--------------------------------
     Reporter:  robgjansen   |      Owner:  robgjansen
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-relay
Actual Points:               |  Parent ID:  #12541
       Points:               |
-----------------------------+--------------------------------

Comment (by robgjansen):

 Thanks for looking over the branch. The lines you reference in Alg 2 were
 primarily there because the prototype we implemented for KIST worked
 exclusively inside of the `connection_write_callback` function in
 `main.c`. In our prototype, KIST only operated on sockets that were in the
 global list of writable sockets.

 In the new implementation, all sockets are 'watched' by the helper thread,
 whether they have data to send or not. Even if the socket has no data in
 Tor, the TCP window could be changing in the kernel due to incoming ACKS,
 so there is some value in doing the calls even in this case.

 One approach is to do the kernel calls for a few seconds after Tor drains
 the app buffer, and then stop until more data was written. To figure out
 when to stop and start the calls, we probably need to add more
 communication between the process and the thread to notify when the socket
 has data in the Tor buffer and not. (I think adding back in the other
 kernel call that I removed in my patch to check the socket length would
 not work, because the socket could be empty at the time of check even
 though more data has been written.)

 I suggest we keep things simple for now (which is certainly OK for
 Shadow), but try to monitor how much overhead the extra calls consume and
 do something like I outlined above if necessary. I do worry, though, that
 this may end up adding more overhead to the main process instead of the
 helper thread, which is probably not what we want.

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


More information about the tor-bugs mailing list