[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] A few ideas about improved design/modularity in Tor
On Mon, Mar 28, 2016 at 6:49 AM, Rob van der Hoeven
<robvanderhoeven@xxxxxxxx> wrote:
>> 2. Add backend abstractions as needed to minimize module coupling. These
>> should be abstractions that are friendly to in- and multi-process
>> implementations. We will need at least:
>>
>> - publish/subscribe{,/acknowledge}.
>>
>> (See
>> https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern.
>> The 'acknowledge' abstraction
>> allows the publisher to wait for every subscriber to acknowledge
>> receipt. More on this in section 4 below.)
>>
>
> Maybe ZeroMQ can do this. See:
>
> https://en.wikipedia.org/wiki/ZeroMQ
>
> and:
>
> http://zeromq.org/
ZeroMQ and its competitors are pretty good, but overkill. They're
designed to work in a distributed environment where with unreliable
network connections, whereas for this application I'm only thinking
about splitting a single Tor instance across multiple processes on the
same host.
> Question: how are these modules you write about implemented? Do you plan
> to make each module a Dll? Will it be possible to only load a Dll if its
> functions are needed? I ask this because I currently have Tor running on
> my router and much of its functions (hidden services, node, etc.) are
> not needed.
I haven't been working on the problem from that angle, but I would
expect that making the code more modular will make it easier only to
compile the modules required.
best wishes,
--
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev