[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Massive Bandwidth Onion Services

This sounds like A really cool Project :)))
I have worked out a hs loadbalancer But only in My mind i havent actually coded it, i Guess i would setup server A as frontend nginx and THE rest as upstream backends to nginx A

Alec Muffett <alec.muffett@xxxxxxxxx> skrev: (19 december 2016 11:30:16 CET)
>I would post this to the tor-onions list, but it might be more
>interesting to folk, so I'm posting here and will shift it if it gets
>I'm working on load-balanced, high-availability Tor deployment
>architectures, and on that basis I am running 72 tor daemons on a
>of 6 quad-core Debian boxes.
>I am then - using Donncha's "OnionBalance" to:
>* scrape the descriptors of those 72 daemons
>* selects random(ish) 60 of the introduction points from those daemons,
>* rebundle those 60 introduction points into 6 distinct descriptors of
>introduction points apiece, then
>* signing those distinct descriptors with a "service" onion address and
>emplacing them onto the HSDir ring.
>This means that, at any one time, the daemon will be able to have 60x
>CPU and network-bus bandwidth, above/beyond what is available to a
>single-daemon instance.
>Why "72"? Because it's a number >60 and I'm seeking to stress-test
>things a
>Specifically: one eventual goal of this project is to adjust the
>timings a
>little, so that the HSDir cache acts a little like "Round-Robin DNS
>Balancing" - people accessing the "service" onion address at lunchtime
>receive/cache different descriptors from those who access it some hours
>later, and the descriptors persist, so thereby the whole 72 daemons get
>used/averaged-out over an entire day.
>In my attempts to go fast-and-wide, however, I appear to have run into
>hardcoded limit:
>Dec 19 09:24:43.365 [warn] HiddenServiceNumIntroductionPoints should be
>between 3 and 10, not 1
>There's little point in publishing >2, and perhaps* not >1 introduction
>point for each of the 72 daemons; also it makes scraping and reassembly
>slower/more expensive.
>So I am writing to ask whether it is possible (and whether it is wise?)
>have a mode that will bypass this (otherwise very sensible) control?
>    -alec
>* it would be rude to an IP to have only a single-IP-per-daemon that
>invariant over a long period, but I believe that IPs migrate over time
>anyway... ?
>tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
>To unsubscribe or change other settings go to

Sincerly flipchan - LayerProx dev
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to