Tor currently has an accounting system for allowing data quota limitations to be applied. This allows a relay to enter &#39;hibernation&#39;, maintaining it&#39;s &#39;up&#39; status, and directory-perceived uptime, without actually relaying traffic. However, it is feasible that an operator might want to control Tor for bandwidth reasons, but not use the built-in accounting system. The relay might share a connection with other applications, and have to change it connection profile relative to them.<div>
<br></div><div>Possible actions that might be desired include:<div>- changing bandwidth limits,</div><div>- changing between an exit and a relay,</div><div>- switching the relay on or off, or</div><div>- suspending dirport operation.</div>
<div><br></div><div>Possible conditions giving rise to such needs include:</div><div>- a periodic quota is reached (since other applications are sharing the connection, Tor can&#39;t be aware of when this limit might be reached), or</div>
<div><div>- another application requires a greater share of the connection temporarily.</div><div><br></div><div>Most of these behaviors are scriptable without difficulty by editing the torrc and sending Tor a sighup. In most cases, this is not a problem. However, when relaying must be suspended - and this suspension is not conducted via the built-in accounting system - the relay is unlisted from directories. Since uptime is used as an index for many of the classifications applied to relays (naming &amp;c), this has a notable effect on the relay&#39;s &#39;profile&#39; in the network, and the way that clients perceive it. Presumably, this is not a desirable situation.</div>
<div><br></div><div><br></div><div>Is there a good workaround for this?</div></div></div>