[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Exceeding connection limit
On Thu, 4 Dec 2008 00:10:11 -0500 Roger Dingledine <arma@xxxxxxx>
wrote:
>On Wed, Dec 03, 2008 at 07:40:54PM -0500, phobos@xxxxxxxxxx wrote:
>> In the manual page, there is:
>> ConnLimit NUM
>> The minimum number of file descriptors that must be available to the
>> Tor process before it will start.
>
>Note that this is the *minimum* number. Basically the config option is
>not useful in this case. (Or most other cases.)
>
>> As for the design questions, I'll let someone else answer that as I
>> can't find the details as to why right now.
>
>Alas, right now the Tor design assumes that all relays can reach all other
>relays. Since clients choose paths randomly, and there are roughly 100
I note, however, that a newly started tor relay does *not* immediately
attempt to establish connections to all other relays currently listed in its
directory as "Running".
>times more clients than there are relays, then pretty much every link
>is going to be in use.
It may once in a while, but the times that I've watched, only a few
connections were frequently transmitting/receiving anything. Further, tor
regularly expires unused connections. Perhaps an option to apply a more
aggressive expiration policy would help users stay within the limitations
of crippled operating systems like Windows.
>
>There are some research directions for "restricted route topologies",
>but they still have some hard challenges. One of the little ones is how
>to grow the topology such that it maintains small-worlds properties
>as new relays join and old relays disappear. One of the big ones is
>communicating the topology to the clients in an efficient way, so they
>can know which links they're allowed to use. Another big one is analyzing
>how much anonymity we lose by making route selection more predictable --
>done right we shouldn't lose much, but I'd need to work out a lot more
>details before really believing it.
Amen.
>
>The more long-term solution for this is to switch to UDP transport between
>relays. Done right, that basically means a few sockets would handle all
>the TLS connections (well, DTLS then), and Tor would get a lot smarter
>about handling the multiplexing between conversations internally. The
>proposals you've seen on here from Joel Reardon and from Camilo Viecco
>would move us in that direction.
>
I still don't understand this. I will try to find time to resume
reading those proposals, but the idea of running stream data over a protocol
with neither sequence preservation nor reliable delivery would be a good
thing goes against all of my experience. For one thing, it would mean that
those things would involve wheel-reinvention inside tor to support those
characterstics of TCP not supported by UDP. For another, an old example
quickly comes to mind: even on a local net, copying large files over NFS is
much slower than using rcp(1) or ftp(1) because NFS uses UDP, while the
latter use TCP.
Has there been any discussion of planning for SCTP with tor at some
point? It looks to me, though I still am reading up on it, as though it
might be a better way to go. (See, for example,
http://www.isoc.org/briefings/017/
for a quick overview of its features and benefits.) My understanding is
that much of the code for it is already in FreeBSD 8-CURRENT, and other
operating system development teams must be working on SCTP implementations,
too, so it should start being available within another two to three years,
I should think.
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at cs.niu.edu *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************