Re: [tor-talk] Massive Bandwidth Onion Services

[Ivan Markin <twim@xxxxxxxxxx>]

Alec Muffett:
> What _could_ happen in the future, is.
> 
> 1) the 72 workers could each set up an IP but *not* publish it in a
> descriptor, and then
> 
> 2) the master daemon could poll the 72 workers for their list of current
> IPs via a backchannel, and then...
> 
> 3) construct the "master descriptor" from that information.
> 
> This has pros and cons.
> 
> It makes the architecture more "active" - using backchannels and lots of
> chattiness - which is great for physically geolocated clusters - ie:
> everything in one rack - but it makes matters *really* complicated for the
> kinds of physically distributed clustering that Tor would be awesome and
> cutting-edge for.

You'll have to do this after prop224 because of onion key
cross-certifications, so fancy plain OnionBalance "renaming" won't work
(HSDir system is unidirectional).
I agree with George, this is not good to upload so many descriptors and
building so many useless circuits. Using backchannels is much more
effective and simple [1]. If you want to retain nice "hole punching"
feature of tor why not just use backchannel onion service (one per
cluster) for this? (Donncha actually mentioned this in the docs).

It may be fun today but tomorrow it won't work.

[1] Not now since they're not implemented. :)
--
Ivan Markin
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk