[tor-bugs] #14943 [Stem]: Triggerable controller event

[Tor Bug Tracker & Wiki]

#14943: Triggerable controller event
-----------------------------+--------------------
     Reporter:  atagar       |      Owner:  atagar
         Type:  enhancement  |     Status:  new
     Priority:  minor        |  Milestone:
    Component:  Stem         |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------
Changes (by atagar):

 * owner:   => atagar
 * component:  Tor => Stem


Comment:

 Reassigning this to Stem. Turns out there's indeed several options. Best
 so far sounds to be listening for CONF_CHANGED then triggering SETCONF
 events (don't forget the corresponding RESETCONF so tests don't leave tor
 in a changed state!).

 {{{
 09:21 < Sebastian> atagar wants an asynch controller command that just
 replies with something
 09:21 < nickm> hmmm
 09:21 < Sebastian> I could implement a ping
 09:21 < Sebastian> but do we have something that already does that?
 09:21 < Sebastian> (The idea is to reply just once)
 09:22 < nickm> Sebastian: what's the application?
 09:23 < atagar> I described it in the ticket - one sec...
 09:23 < Sebastian> It would make the tests a lot faster
 09:23 < Sebastian> currently atagar uses bw events for taht
 09:23 < Sebastian> that*
 09:23 < atagar> Not a lot, but a few seconds.
 09:23 < nickm> oh, easy
 09:23 < nickm> SETEVENTS ADDRMAP
 09:23 < nickm> 250 OK
 09:23 < nickm> RESOLVE 127.0.0.1
 09:23 < nickm> 650 ADDRMAP 127.0.0.1 127.0.0.1 "2015-02-19 12:21:25"
 EXPIRES="2015-02-19 17:21:25" CACHED="NO"
 09:23 < Sebastian> thanks for correcting that, atagar. I had hoped for a
 lot
 09:23 < nickm> 250 OK
 09:23 < atagar> ah, there it is -
 https://trac.torproject.org/projects/tor/ticket/14943
 09:23 < nickm> probably there's other stuff too
 09:24 < nickm> note that if you resolve something that is already an IP,
 it doesn't hit the network
 09:24 < atagar> If you don't have network connectivity does that work? I'd
 expect RESOLVE to fail, so suspect it wouldn't emit an event.
 09:24 < nickm> I bet it will succeed if you tell it 127.0.0.1
 09:24 < Sebastian> easy to test
 09:25 < Sebastian> just disablenetwork
 09:25 < nickm> works for me with disablenetwork set
 09:25 < nickm> haven't tried it with no internet connectivity
 09:25 < atagar> Also the tests shouldn't touch the network if running
 without the online target - if it doesn't then perfect.
 09:25 < nickm> it shouldn't.
 09:25 < atagar> great - thanks!
 09:25 < Sebastian> ok, thankss. Will have to find something else to
 implement then :)
 09:26 < Sebastian> I'll write the stem patch if you don't want to do it
 atagar?
 09:26 < nickm> another option is listen for SIGNAL then send a SIGNAL
 CLEARDNSCACHE
 09:26 < nickm> maybe
 09:26 < nickm> let me check
 09:26 < atagar> Sebastian: I was just about to ask that. :P
 09:26 < nickm> yup, that works too
 09:26 < atagar> Have quite a few other things on my plate so if you're up
 for writing it that would be appreciated.
 09:27 < nickm> Or listen for CONF_CHANGED and then set Contact or
 something
 09:27 < Sebastian> atagar: ok cool. I am in a train so no real computer
 and no real network
 09:27 < Sebastian> Can you file a bug and assign it?
 09:27 < atagar> oooh, CONF_CHANGED sounds like the best so far
 09:27 < atagar> thanks nickm
 09:27 < Sebastian> I'll implement it
 09:27 < Sebastian> thanks both of you :)
 09:27  * nickm is just breezing through control-spec.txt
 09:27 < atagar> Sebastian: Will do. I'll reassign the existing ticket and
 add this backlog.
 09:27 < Sebastian> (the great thing about this is that it doesn't even
 need a feature-gate)
 }}}

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