[tor-bugs] #11400 [Flashproxy]: Status lists itself as "dead"	inaccurately
    Tor Bug Tracker & Wiki 
    blackhole at torproject.org
       
    Wed May 21 00:53:05 UTC 2014
    
    
  
#11400: Status lists itself as "dead" inaccurately
----------------------------+--------------------------
     Reporter:  saint       |      Owner:  dcf
         Type:  defect      |     Status:  needs_review
     Priority:  normal      |  Milestone:
    Component:  Flashproxy  |    Version:
   Resolution:              |   Keywords:
Actual Points:              |  Parent ID:
       Points:              |
----------------------------+--------------------------
Changes (by dcf):
 * status:  new => needs_review
Comment:
 Here's a summary of my thinking:
  1. The code transitions to "dead" in all the places it was meant to.
  2. However, "dead" doesn't work the way it was meant to: it was supposed
 to turn off all future network activity, just like "disabled" does.
  3. However however, it appears that this behavior is not what Cupcake
 wants--it wants to continue polling after a network error.
 The "dead" state was meant as a failsafe in order to prevent runaway
 behavior caused by potential bugs--for example a proxy repeatedly polling
 a facilitator that is down for some reason. This attachment makes "dead"
 work the way it was meant to. It only has an effect for the places where
 this.die is called after a network error--during argument parsing the
 badge can die, but it also hasn't scheduled a timer callback yet.
  * attachment:0001-Make-die-really-die.patch
 However, it sounds like Cupcake doesn't want the proxy to die at the first
 network error. Therefore this second patch removes the calls to this.die
 after network errors. The effect is that the proxy will soldier on after a
 network error (as it has always been doing, through unintentionally)--the
 only difference is that the badge will no longer change color.
  * attachment:0002-Don-t-die-on-network-errors-rather-try-again.patch
 How do these patches work for you? An alternative to the second patch is
 to increment a counter or something, and then actually die (up until the
 next daily refresh) after a threshold is passed.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11400#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
    
    
More information about the tor-bugs
mailing list