add NumCpus config variable in preparation for cpuworkers
hardcode /etc/torrc path for config (simplifies win32 port)
improve exit policy debugging during router entry parsing


svn:r397

svn:r371

svn:r340

svn:r323

The culprit: sometimes DH_calculate_key returns less than DH_KEY_LEN bytes;
we needed to check the return value.


svn:r322

svn:r319

they used to be used for
* queueing relay cells at the edge of the network, when windows are empty
* queueing relay cells that arrive after an onion but before the onion
  has been processed.
both of these uses are gone. so out they go.


svn:r315

clean up circuit_deliver_relay_cell convention


svn:r312

svn:r304

svn:r298

svn:r295

circuits no longer queue more cells when the windows are empty --
they simply don't package it from the buffer if they're not going to want it.

we can restore this code later if we need to resume queueing.


svn:r294

remove sendme cells
replace malloc with tor_malloc
patch (but not track down) bug in onion pending list
streamline connection_ap handshake


svn:r293

svn:r274

svn:r266

svn:r265

still need to change circuit-level sendmes


svn:r264

svn:r263

the OP only crypts the appropriate number of times depending on which
layer (hop on the path) it's for/from.


svn:r262

svn:r260

svn:r259

svn:r258

svn:r250

svn:r249

svn:r239

svn:r238

svn:r236

now we rebuild the circuit periodically (but only if it's been used),
and we can further abstract it to do incremental circuit building, etc.


svn:r233

route selection still doesn't pay attention to exit policies though


svn:r227

svn:r224

svn:r198

if your ORPort is non-zero then you must connect to all nodes
if your DirPort is non-zero then you must act like a directory server


svn:r192

svn:r186

serious performance increase over non-caching


svn:r158

on startup, it forks off a master dns handler, which forks off dns
slaves (like the apache model). slaves as spawned as load increases,
and then reused. excess slaves are not ever killed, currently.

implemented topics. each topic has a receive window in each direction
at each edge of the circuit, and sends sendme's at the data level, as
per before. each circuit also has receive windows in each direction at
each hop; an edge sends a circuit-level sendme as soon as enough data
cells have arrived (regardless of whether the data cells were flushed
to the exit conns). removed the 'connected' cell type, since it's now
a topic command within data cells.

at the edge of the circuit, there can be multiple connections associated
with a single circuit. you find them via the linked list conn->next_topic.

currently each new ap connection starts its own circuit, so we ought
to see comparable performance to what we had before. but that's only
because i haven't written the code to reattach to old circuits. please
try to break it as-is, and then i'll make it reuse the same circuit and
we'll try to break that.


svn:r152

when we had lots of new onions coming in, we were using 40% of
our time searching through the tracked_onions linked list.


svn:r150

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


svn:r146

this was a major faq, because it would fail with an error only on
the *server* side when the client-side time was wrong. the client would
simply not work.


svn:r145

svn:r143

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