[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #14943 [Stem]: Triggerable controller event
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs