we're closer to an OS X port
 CVS: ----------------------------------------------------------------------


svn:r146

we also queue data cells destined for a circuit that is
pending, and process them once the circuit opens

destroys reach into the queue and remove the pending onion,
along with its collected data cells


svn:r142

first cut, probably needs more playing with


svn:r137

reformat parts of onion.c


svn:r136

svn:r133

now tor can be run safely inside nat'ed areas that kill idle
connections; and the proxy can handle when you suspend your laptop
and then emerge hours later from a new domain.


svn:r125

prkey is only fetched when it's needed
tor nodes who aren't dirservers now fetch directories and autoconnect
  to new nodes listed in the directory
default role is a non-dirserver node


svn:r120

proxies now periodically pull down an hourly-updated directory,
and replace their router list with it if it parses correctly.


svn:r112

svn:r96

svn:r89

svn:r88

svn:r86

svn:r79

Each socket reads at most 'bandwidth' bytes per second sustained, but
can handle bursts of up to 10*bandwidth bytes.

Cells are now sent out at evenly-spaced intervals, with padding sent
out otherwise. Set Linkpadding=0 in the rc file to send cells as soon
as they're available (and to never send padding cells).

Added license/copyrights statements at the top of most files.

router->min and router->max have been merged into a single 'bandwidth'
value. We should make the routerinfo_t reflect this (want to do that,
Mat?)

As the bandwidth increases, and we want to stop sleeping more and more
frequently to send a single cell, cpu usage goes up. At 128kB/s we're
pretty much calling poll with a timeout of 1ms or even 0ms. The current
code takes a timeout of 0-9ms and makes it 10ms. prepare_for_poll()
handles everything that should have happened in the past, so as long as
our buffers don't get too full in that 10ms, we're ok.

Speaking of too full, if you run three servers at 100kB/s with -l debug,
it spends too much time printing debugging messages to be able to keep
up with the cells. The outbuf ultimately fills up and it kills that
connection. If you run with -l err, it works fine up through 500kB/s and
probably beyond. Down the road we'll want to teach it to recognize when
an outbuf is getting full, and back off.


svn:r50

svn:r47

svn:r42

svn:r41

svn:r40

svn:r36

svn:r31

svn:r28

svn:r26

svn:r25

svn:r2