<html><head></head><body><div class="ydp81ad5332yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div>David/Roger:</div><div><br></div><div>Search the tor-relay mail archive for my previous responses on loadbalancing Tor Relays, which I've been successfully doing for the past 6 months with Nginx (it's possible to do with HAProxy as well). I haven't had time to implement it with a Tor Bridge, but I assume it will be very similar. Keep in mind it's critical to configure each Tor instance to use the same DirectoryAuthority and to disable the upstream timeouts on Nginx/HAProxy.</div><div><br></div><div>Happy Tor Loadbalancing!</div><div><br></div><div>Respectfully,</div><div><br></div><div><br></div><div>Gary</div><div><br></div><div>P.S. I believe there's a torrc config option to specify which cpu core a given Tor instance should use, too.</div>
        <div><br></div><div><br></div>
        
        <div id="ydp81ad5332yahoo_quoted_0932520643" class="ydp81ad5332yahoo_quoted">
            <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
                
                <div>
                    On Monday, December 27, 2021, 2:00:50 PM MST, Roger Dingledine <arma@torproject.org> wrote:
                </div>
                <div><br></div>
                <div><br></div>
                <div>On Mon, Dec 27, 2021 at 12:05:26PM -0700, David Fifield wrote:<br clear="none">> I have the impression that tor cannot use more than one CPU core???is that<br clear="none">> correct? If so, what can be done to permit a bridge to scale beyond<br clear="none">> 1×100% CPU? We can fairly easily scale the Snowflake-specific components<br clear="none">> around the tor process, but ultimately, a tor client process expects to<br clear="none">> connect to a bridge having a certain fingerprint, and that is the part I<br clear="none">> don't know how to easily scale.<br clear="none">> <br clear="none">> * Surely it's not possible to run multiple instances of tor with the<br clear="none">>   same fingerprint? Or is it? Does the answer change if all instances<br clear="none">>   are on the same IP address? If the OR ports are never used?<br clear="none"><br clear="none">Good timing -- Cecylia pointed out the higher load on Flakey a few days<br clear="none">ago, and I've been meaning to post a suggestion somewhere. You actually<br clear="none">*can* run more than one bridge with the same fingerprint. Just set it<br clear="none">up in two places, with the same identity key, and then whichever one the<br clear="none">client connects to, the client will be satisfied that it's reaching the<br clear="none">right bridge.<br clear="none"><br clear="none">There are two catches to the idea:<br clear="none"><br clear="none">(A) Even though the bridges will have the same identity key, they won't<br clear="none">have the same circuit-level onion key, so it will be smart to "pin"<br clear="none">each client to a single bridge instance -- so when they fetch the bridge<br clear="none">descriptor, which specifies the onion key, they will continue to use<br clear="none">that bridge instance with that onion key. Snowflake in particular might<br clear="none">also want to pin clients to specific bridges because of the KCP state.<br clear="none"><br clear="none">(Another option, instead of pinning clients to specific instances,<br clear="none">would be to try to share state among all the bridges on the backend,<br clear="none">e.g. so they use the same onion key, can resume the same KCP sessions,<br clear="none">etc. This option seems hard.)<br clear="none"><br clear="none">(B) It's been a long time since anybody tried this, so there might be<br clear="none">surprises. :) But it *should* work, so if there are surprises, we should<br clear="none">try to fix them.<br clear="none"><br clear="none">This overall idea is similar to the "router twins" idea from the distant<br clear="none">distant past:<br clear="none"><a shape="rect" href="https://lists.torproject.org/pipermail/tor-dev/2002-July/001122.html" rel="nofollow" target="_blank">https://lists.torproject.org/pipermail/tor-dev/2002-July/001122.html</a><br clear="none"><a shape="rect" href="https://lists.torproject.org/pipermail/tor-commits/2003-October/024388.html" rel="nofollow" target="_blank">https://lists.torproject.org/pipermail/tor-commits/2003-October/024388.html</a><br clear="none"><a shape="rect" href="https://lists.torproject.org/pipermail/tor-dev/2003-August/000236.html" rel="nofollow" target="_blank">https://lists.torproject.org/pipermail/tor-dev/2003-August/000236.html</a><br clear="none"><br clear="none">> * Removing the fingerprint from the snowflake Bridge line in Tor Browser<br clear="none">>   would permit the Snowflake proxies to round-robin clients over several<br clear="none">>   bridges, but then the first hop would be unauthenticated (at the Tor<br clear="none">>   layer). It would be nice if it were possible to specify a small set of<br clear="none">>   permitted bridge fingerprints.<br clear="none"><br clear="none">This approach would also require clients to pin to a particular bridge,<br clear="none">right? Because of the different state that each bridge will have?<br clear="none"><br clear="none">--Roger<div class="ydp81ad5332yqt0819046150" id="ydp81ad5332yqtfd74864"><br clear="none"><br clear="none">_______________________________________________<br clear="none">tor-relays mailing list<br clear="none"><a shape="rect" href="mailto:tor-relays@lists.torproject.org" rel="nofollow" target="_blank">tor-relays@lists.torproject.org</a><br clear="none"><a shape="rect" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" rel="nofollow" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br clear="none"></div></div>
            </div>
        </div></div></body></html>