Re: [tor-bugs] #11400 [Flashproxy]: Status lists itself as "dead" inaccurately

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs