On Sat, 4 Jul 2015 19:34:45 -0400 Ben Serebin ben@reefsolutions.com wrote:
I'll hijack the response.... I'm a sysadmin, an unloved Windows one. My unwanted $0.02 are:
- Windows installer (omg, Windows, the evil one which if you really
want greater adoption is the answer! Oh smokes, someone said it!
Ignoring this, not a platform I use or particularly care about, etc.
- change the architecture so running behind nat works (this is
probably the #1 limit factor for increasing relays). Every tom, dick, and harry could then add bandwidth via every internet circuit. It would be insane!
Running relays behind NATs does work, you either need to setup port forwarding manually or provide a tor-fw-helper executable, with the former being massively preferable.
"tor-fw-helper" isn't being distributed/built at all despite having had a portable rewrite (Check my github repo), instead of the C code that depends on a bunch of sketchy library code (included in the tor source tree), because:
a) A lot of uPnP/NAT-PMP implementations on the router side are utterly horrific, and will crash if you look at them funny.
b) Playing tech support for people that encounter "a" is not something I can personally do, and probably neither the support team.
c) A person that can't figure out port forwarding probably should not be running a relay in the first place.
An important thing to consider here is that, beyond bandwidth relay uptime and stability are also important considerations, which is not something usually obtainable from someone's home computer (eg: people turning it off at night).
If by this you mean, "make relays work from behind NATs without port forwarding in any shape or form" that's a far trickier prospect. It's important that every relay can talk to every other relay, and TCP NAT traversal when both boxes are behind NATs requires a intermediary of some sort (See: http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf for a reasonable intro to how this works[0]).
Regards,