[tor-dev] txtorcon [GSoC 2013]
anshul.singhle at gmail.com
Tue Apr 16 17:12:55 UTC 2013
Thanks for the reply and the useful links!
I went through txtorcon and stem a bit. Also skimmed through the
control spec a bit. I'll now give an overview of what this project is,
please correct me if I got something wrong.
So basically tor has a control protocol that allows clients to connect
to it, the spec is in the control-spec doc. txtorcon is a
twisted-based implementation of this protocol.
The aim of this project would be to use the protocol-parsing from stem
instead of using the "re-implementation" in txtorcon. Since the
protocol parsing is synchronous anyway(AFAICT) it makes sense to do
Therefore, it would also make sense to identify other synchronous
activities being done by txtorcon and use Stem to do those too (since
we will be instantiating a stem object anyway).
So as I see it, the majority of the changes will be in
and in that in the TorControlProtocol and TorProtocolError
parts(mainly) These classes have some functions that are used by
others and some which are for internal use(i guess the ones with _ are
internal if I got the naming convention right). So we will just throw
away the internal functions(should we?) and keep the external function
api the same, the difference being these external functions will now
call stem instead of doing the heavy lifting themselves.
I have a question about LineOnlyReciever - Are there other types of
receivers which txtorcon doesn't implement but stem does? If we are
integrating the two it would be good to optionally add API's for
these. Is this the primary reason for doing this integration? Or is it
just better for tor if all the protocol specific code is one place so
that it is easy to adapt to any changes in the API?
So in essence i guess my questions is - What is the primary focus of
this project - Is it to bring the protocol specific code in one place
or to use Stem wherever possible? or both?
More information about the tor-dev