[tor-dev] A few ideas about improved design/modularity in Tor

[Nick Mathewson]

On Mon, Mar 28, 2016 at 6:49 AM, Rob van der Hoeven
<robvanderhoeven at ziggo.nl> 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