Fosforo schreef op 16/07/14 14:15:
I am a big fan of pinkmeth hidden service ( hxxp://pinkmethuylnenlz.onion/ ) But it constantly times out. As an unix administrator, I was thinking in ways to escalate such good public services through normal clusters, and would like opinions if my approach is valid, to suggest it to the unknown author: 1) Frontend - Only 1 node. Entry point as normal "semi-hidden" hidden service with 32 guards (exposed, semi-hidden) 2) Backend - X number of nodes (escaling is here) numbers of backend hidden services with 3 guards 1) is just a relay box, nginx with reverse connection to backend hidden services, in a different structure than backends. round robin. 32 guards to handle good speed and lots of circuits. anonymity is not a requirement here. each backend hidden service is a local port in 127.0.0.1 made with torified netcat (I think there are better approaches than netcat, would like to know ) 2) apache+mysql each node, gfs filesystem (for static files) shared among nodes, replicated mysql database. I see latency as a problem here [ user -> nginx (hidden) -> apache (hidden) ], but I dont see more timeouts. thoughts?
I think that, depending on the specific case (I don't know this 'pinkmeth'), there are some far better solutions for this :
* Find a better network for the servers and instead of doing 'nginx -> tor -> apache' just go 'nginx -> apache'. You can of course still use SSL to encrypt the data inbetween. This reduces a lot of latency.
* Rather than putting everything on a single domain, just put only the HTML on the primary .onion domain and put all static content, such as stylesheets, videos and images, on a different server. You could scale the static content part really well by just returning one of several .onion domains that all have your static content. Give the user a small cookie that can be used to make sure the same static server is always used for the same user.
* As far as I can tell nothing in the hidden service spec really blocks you from load balancing a single HS address across multiple nodes. If you run 3 nodes, tell 1 of them to handle the introductions, and have this node communicate with the other nodes which then handle the rendezvous part. It might need some hacking in the Tor code, but this should scale for several gigabits very nicely.
TomPS: These three are just some solutions I came up with just now - they might not even work.
-- 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