Re: [tor-talk] Tor and P2P

[grarpamp <grarpamp@xxxxxxxxx>]

>> My question is, how would it scale and what would be the implications
>> of such a system (every user would be a hidden service and would be
>> constantly connected to other hidden services it wants to interact
>> with)?

> thrash the HS
> directory system excessively, and probably overload the users' Tor
> client processes to the point that they start pounding on the Tor
> network in general

I likely ran into some of this a while back with something I was
working on, enough that it forced a hardware upgrade and future
tests.

If you're expecting to be doing lots of session initiation, I think
you're going to hit some significant local CPU issues, especially
those of you thinking of P2P applications running on "smaller than
laptop" devices. An occaisional message in the manner in which you
might normally 'text', would work ok. But if you expect to have
some sort of pidgin/sip buddy list full of status and people bouncing
around doing things, it could become ugly. Certainly far worse for
torrenting as the extreme example. And when thousands of people
come online with P2P like that... yeah.

On the other hand, once the session state is up, things seem better
and you're back to the usual latency, bandwidth and reliability
limits of the relay system.

P2P doesn't generally keep sessions up, so it's back to step one.


> 1. Persistent hidserv connections. Reconnecting for each message via an
> HTTP POST is right out. Way too many circuits+onionskins to scale.

So it would be interesting to see where this could go.
- Extending circuit and other timeouts for hidden services?
- Storing related TCP or Tor states locally?
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk