[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
>generally
>interesting to folk, so I'm posting here and will shift it if it gets
>too
>technical.
>
>
>I'm working on load-balanced, high-availability Tor deployment
>architectures, and on that basis I am running 72 tor daemons on a
>cluster
>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,
>and
>
>* rebundle those 60 introduction points into 6 distinct descriptors of
>10
>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
>the
>CPU and network-bus bandwidth, above/beyond what is available to a
>typical
>single-daemon instance.
>
>Why "72"? Because it's a number >60 and I'm seeking to stress-test
>things a
>little.
>
>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
>Load
>Balancing" - people accessing the "service" onion address at lunchtime
>will
>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
>a
>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?)
>to
>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
>was
>invariant over a long period, but I believe that IPs migrate over time
>anyway... ?
>
>-- 
>http://dropsafe.crypticide.com/aboutalecm
>-- 
>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

-- 
Sincerly flipchan - LayerProx dev
-- 
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