Re: two unseemly tor behaviors

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Tue, 3 Jul 2007 18:13:14 -0400 phobos@xxxxxxxxxx wrote:

>On Tue, Jul 03, 2007 at 12:33:04PM -0500, bennett@xxxxxxxxxx wrote 5.7K bytes in 104 lines about:
>:      I'm sorry, but I cannot agree.  How is crashing a running server better
>: than somebody missing a message?  After all, sending SIGHUP is a manual
>
>	It happens far more often than you may think.  Someone changes a
>	config file option, hup's tor and assumes all is working well.
>	It's not until they either try to use the now stopped Tor or
>	notice their server is offline that they come seeking help.
>	Generally, it's after someone asks for a copy of the logfile
>	that they notice the messages about a broken config.

     Do you think that they prefer to have their server crash, rather than
to issue an error message and continue operations?  And that such behavior
benefits the worldwide community of tor users?
     Most of the changes that I make while tor is running are to a) bandwidth
rate limits and b) exit policies.  A day or two ago, I was revisiting the list
of port numbers for which I'm willing to offer exit service.  After adding at
least 30 or 40 ports to that list, I sent SIGHUP to tor, and it immediately
exited with an error message about a semicolon instead of a colon in one of
the lines I had added/changed.  More than 60 exit circuits alone were broken
without any warning to those using them.  I have no idea how many circuits
were broken that did not exit from my server.  What would have been the harm
in simply rejecting the one ExitPolicy line in error?  Or in ignoring the
whole torrc as offered to tor at that time?  The error message issued would
have enabled me to fix the bad character and resubmit my changes to tor without
disrupting any operations at all.
     To keep those who feel that reliability is not nearly as important as
beating the server operator and users of circuits through it over the head with
crashes, how about an option to promote such crashes or to continue operations
after logging messages about the rejected torrc line or file?  That would
settle the issue and would allow those of us who want to to do our parts to
keep the tor network running smoothly.
>
>:      I think anyone who has been patiently waiting for a download to complete
>: over tor circuit that creeps along at the common tor circuit speed of ~3KB/s
>: would appreciate more reliable circuits that give a better chance that the
>: download *will* complete, rather than die 90% of the way through because
>: someone typed a semi-colon instead of a colon in torrc.
>
>	Tor will use a new circuit and generally put the traffic over
>	that new circuit.  In practical experience, my tcp traffic seems
>	to re-establish and downloads (of pages, email, etc) continue
>	with just a minor pause.
>
     My own experience contradicts that.  I frequently find downloads that have
quit early, saying that they are "done", but when the downloaded file is
checked, its size is only a fraction of the size it ought to be.  I count
myself as one of those who await the day when connections through the tor
network become vastly more durable/reliable than they are now, which is the
main reason I always change ShutdownDelay from the trivial default to a much
longer time period.
     Further, the tor documentation itself says that a given TCP connection
is lost when a circuit is broken.  tor does *not* build a new circuit and
restart or continue the operation that was terminated.  When you think about
it, tor *couldn't* do that unless it understood the protocol in use that ended
early and had been monitoring its progress.  In many cases, tor would also have
to keep track of loginids and passwords in order to repair and continue the
interrupted traffic on a rebuilt circuit.  *New* traffic does go over new
circuits after circuits fail, but the traffic that was going at the time of
failure does not.
     There may be some types of downloader clients that will retry an operation
that has ended prematurely, as you suggest, but it is quite apparent that
Firefox's built-in downloader does not, and tor itself does not.


                                  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         *
**********************************************************************