accounting vs long lived nodes

[David Vennik]

Watson Ladd wrote:
> David Vennik wrote:
>> Michael Tharp wrote:
>> ...
>>>> If a node has bandwidth accounting, it should not be listed as long
>>>> lived, because obviously it is likely to go down at any moment. I don't
>>>> know if it will make that much difference to persistent session use on
>>>> tor or not, but I think that it is only logical that bandwidth
>>>> accounting should flag a 'not long lived' flag on the server information
>>>> so that circuits to irc and ssh and other long lived connections don't
>>>> use it. i know this might 'reduce anonymity' through the weakening of
>>>> defenses against traffic analysis, but endless reconnections to irc
>>>> servers, in my experience, is annoying both to myself and to the endless
>>>> timeouts in the ORC which is exclusively tor-accessible.
>>>>
>>>> Regards,
>>>>
>>>> David Vennik
>>>>   
>>> Doesn't tor already have this? Connections to certain ports (21, 22, 80
>>> among others) that are typically reserved for long-lived connections
>>> will avoid nodes that have been up for less than a certain amount of time.
>>>
>> you are missing my point. if a node has bandwidth accounting configured
>> it may stay up for a week but it could hibernate in five seconds. this
>> is not helpful for users of persistent connection based services. some
>> kind of flag on the server description suggesting that the server is
>> liable to go offline at any time would be very useful for preventing the
>> endless string of timeouts that using tor for these kinds of connections
>> causes.
> Why doesn't tor close the connection when the circuit fails?
> 
that's a good question, it sometimes does but sometimes not. i think it
depends on whether its the exit or entry node which dies, if the
middleman dies then neither end has a connection drop... i'm not sure
how it works, i'm sure someone who knows what happens can explain it to us

-- 
http://davidvennik.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: davidvennik.vcf
Type: text/x-vcard
Size: 300 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20061022/ac81a345/attachment.vcf>