[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