On 12/04/13 15:03, Moritz Bartl wrote:
On 12.04.2013 13:33, Matt Joyce wrote:
I assume you mean firewall-based blocking? You could have simply rejected those IPs via ExitPolicy (see "man tor"). That's a clear-cut way to tell the network you don't accept connections to those IPs, and no risk of being labeled a BadExit.
The latter. I dont know if it complicates routing decisions in the Tor network to have lots of ip address exceptions at the exits...
It possibly does slightly but we are talking about the sort of "complication" that a modern CPU can resolve in timescales short enough I doubt it would make that much difference especially if hash tables were used
That's not the issue here. You don't want to make the "routing table" (consensus and descriptors) that every Tor client needs to have too large. Users in developing countries, on mobile connections or generally instable connections already have issues.
It would help a lot if we used versioning and stopped sending almost unchanged data constantly and instead only providing the changes they are after all text files and there is a whole range of open source projects out there with the functionality to manage versioning and incremental updates for text files, the tradeoff of course would be in the slightly increased disk space requirements for dirmirriors.
That said I'm not arguing that we *should* do this merely that it is possible and there are technical options to accommodate it if it were required by enough of the community to pose a potential issue. Basically my point is that the it's possible the question therefore more one of whether we should, I don't particularly see the need and there are arguments against it I don't like censorship at the best of times which is why I run the exits I have I am just countering the technical arguments which I believe are potentially solvable if there was consensus that it is warranted and therefore are not good reasons to dismiss the idea.
As for the unstable connections issue, yeah that I can understand that said tor uses TCP only and TCP is *known* to perform at less than optimum in the event of unstable connections with random drops, it will get the data there but it will also do it very slowly interpreting dropped packets as congestion. Radio communications frequently cause TCP to have problems which is why the FAQ for almost any high bandwidth TCP application will invariably suggest things like "Use a hardwired connection if possible not wireless". I'm not dismissing it as an issue of course but no TCP application is going to work well if the underlying network infrastructure is poor and I am not sure how that is going to be solved without A) Replacing TCP with something else (But what?) or B) Major investment in those networks which is unfortunately unlikely until there is a large enough user base to create the demand to make someone with capital actually pay the slightest bit of attention because they generally are only interested when they can generate a profit.