Re: [tor-dev] Load Balancing in 2.7 series - incompatible with OnionBalance ?

On 23 Oct 2015, at 03:30, Alec Muffett wrote: >> However, if you were to use proposal #255 to split the introduction and >> rendezvous to separate tor instances, you would then be limited to: >> - 6*10*N tor introduction points, where there are 6 HSDirs, each receiving >> 10 different introduc

Re: [tor-dev] Load Balancing in 2.7 series - incompatible with OnionBalance ?

On 23 Oct 2015, at 03:30, Alec Muffett wrote: >> However, you mention that one DC going down could cause a bad experience for >> users. In most HA/DR setups I've seen there should be enough capacity if >> something fails, is that not the case for you? Can a single data center not >> serve all

Re: [tor-dev] Hello, after about one hour since my Tor browser successfully connected to Tor network with a obfs4 bridge, I couldn't open any webpage through Tor proxy.

On Thu, Oct 22, 2015 at 11:53:15PM +0800, Li Xiaodong wrote: > Hello, after about one hour since my Tor browser successfully connected to Tor > network with a obfs4 bridge, I couldn't open any webpage through Tor proxy. > But > after I restarted my Tor browser, Tor browser can work normally again.

Re: [tor-dev] Load Balancing in 2.7 series - incompatible with OnionBalance ?

On 22 Oct (16:30:55), Alec Muffett wrote: > > i...@tvdw.eu wrote: > > > Hi Alec, > > Hi Tom! I love your proposal, BTW. :-) > > > Most of what you said sounds right, and I agree that caching needs TTLs > > (not just here, all caches need to have them, always). > > Thank you! > > > However, y

Re: [tor-dev] Load Balancing in 2.7 series - incompatible with OnionBalance ?

i...@tvdw.eu wrote: > Hi Alec, Hi Tom! I love your proposal, BTW. :-) > Most of what you said sounds right, and I agree that caching needs TTLs (not > just here, all caches need to have them, always). Thank you! > However, you mention that one DC going down could cause a bad experience for

[tor-dev] Hello, after about one hour since my Tor browser successfully connected to Tor network with a obfs4 bridge, I couldn't open any webpage through Tor proxy.

*Hello, after about one hour since my Tor browser successfully connected to Tor network with a obfs4 bridge, I couldn't open any webpage through Tor proxy. But after I restarted my Tor browser, Tor browser can work normally again. Does China's firewall disturb obfs4 bridges? Thank you very much for

Re: [tor-dev] Faster Bootstrap - Prop #210 (Revised)

Hi All,I have continued to revise and implement proposal #210: Faster Headless Consensus Bootstrap.This proposal aims to improve tor’s consensus download behaviour when the authorities (or directory mirrors) are down. It has tor initiate multiple concurrent consensus connections, then download the

[tor-dev] Proposal: Rendezvous Single Onion Services

Hi All,Please find below and attached a proposal: Rendezvous Single Onion Services.This is an updated and expanded version of "Direct Onion Services: Fast-but-not-hidden services”. It also borrows heavily from "Single Onion Services" (Proposal #252).The proposal is available in the branch “feature-

[tor-dev] Status of Open Hidden Service Proposals (October 2015)

Greetings, it's well known that hidden services need some love: https://blog.torproject.org/blog/hidden-services-need-some-love For the past 2 years we've been busy designing the upcoming hidden service protocol with improved cryptography, security, and performance. During this time we've writte

Re: [tor-dev] Load Balancing in 2.7 series - incompatible with OnionBalance ?

Alec Muffett writes: > typo: > >> alecm: and this persists for up to 24h, even though the outage was only 10 >> minutes > > Also, I neglected to observe that linear polling of A-E seeking a descriptor > suggests A will be hammered whilst J is nearly idle. > > Some entropy in IP selection would

Re: [tor-dev] Proposal: Load-balancing hidden services by splitting introduction from rendezvous

Tom van der Woerdt writes: > Op 04/10/15 om 06:46 schreef Tim Wilson-Brown - teor: >> >>> On 3 Oct 2015, at 13:34, Tom van der Woerdt >> > wrote: >>> ... >>> 3. Compatibility and security >>> >>> The implementation of these methods should, ideally, not change >>> anything in