<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
What OS are you using? I used to have this problem all the time with
Windows, and it got worse over time as the system got more and more
FUBARed. However, since switching entirely to Linux, I have not had any
of these issues more than once every week or so. This is just my case
though perhaps others have this issue on other platforms more
frequently.<br>
<br>
~Andrew<br>
<br>
glymr wrote:
<blockquote cite="mid43D44145.3020805@ml1.net" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Hi,<br>
<br>
I've been running a tor server on and off for some time, I just
recently got a dsl connection again, only a measly 256/64 connection,
and one of my main uses for tor has always been instant messaging. <br>
<br>
One of the most annoying things about tor, as it is presently run, for
instant messaging purposes, is getting circuits which die frequently. I
have an idea about how this problem could be solved, and I feel that
this idea should be promoted at tor.eff.org - of specialised
interactive traffic only nodes. This could be integrated into the
configuration system in fact. The rules for how to define what one
should set a node to do are as follows:<br>
<br>
<blockquote>1. If a node is run which is frequently offline, but with
high bandwidth, this is suited to short-lived traffic, such as
downloads of files (p2p, web browsing).<br>
<br>
2. If a node has low bandwidth, and can be kept online for long periods
of time, this is the ideal situation for low-volume interactive traffic.<br>
</blockquote>
<br>
These rules could be used to weight classes of ports, a node could keep
a history of its uptime, and report its average uptime value
accumulated over time to the directory. This would help for choosing
interactive traffic routes, the longer the average uptime, the greater
the chance of it being picked on interactive circuits.<br>
<br>
A cumulative history of average bandwidth usage would be added to this,
and through the combination of these two, routers could create a pair
of different classes of circuits, long lived circuits and short lived
circuits, and one could overlay this and create another two classes of
circuit, short-lived, low bandwidth circuits and long-lived
high-bandwidth circuits. This second set of classes is probably not so
important.<br>
<br>
Tor could automatically select it's preference for the different
traffic classes according to these values. At this point, without an
automated system to do this, it can be done by users (as I am doing) -
by using a rate-limiting system (netlimiter) and allowing only a small
set of interactive traffic types through (in my case, irc and silc) -
since tor precludes the use of file transfers on these two protocols, I
set the rate limiting between 2 and 4kb/s depending on whether I am
downloading more or chatting more.<br>
<br>
However, I think it would be a worthwhile addition to the system by
which Tor does its routing to use these rules in both the production of
an uptime and bandwidth average, which is used by clients to select a
pair of different circuit classes, interactive and high volume. High
volume traffic usually is short lived, and interactive traffic is
usually long lived. By specialising the circuits according to these
rules one would find that interactivity is better promoted, and
separated from volume.<br>
<br>
David<br>
</blockquote>
</body>
</html>