choose an intro point, connect to it,
choose a rend point, connect to it and establish a cookie,
get an ack from the rendezvous point,
and know when both circs are ready for her.
APConns don't use conn->purpose anymore
don't initiate a renddesc lookup if one is already in progress
also fix a buffer overflow in nickname parsing (only exploitable
by the operator though)
svn:r1471
* read all the time (before we would ignore eof sometimes, oops)
* we can handle different urls now
* send back 404 for an un-handled url
* commands initiated by the client can handle payloads now
* introduce conn->purpose to avoid exponential state-space explosion
svn:r1400
successful/failed connections, successful/failed extends, and
connection uptimes.
It's still not done: more tests are needed, and not everything calls
connection/circuit_mark_for_close properly. This skews the results.
Also, there needs to be a 'testing' mode for non-OP ORs, where they
periodically build circuits just to test whether extends work.
svn:r1313
we were never writing anything when hold_open_until_flushed was set,
since conn_write returns early if marked_for_conn is set.
seems a bit better now.
svn:r1214
Apparently, when a DNS failure was already cached, then when we tried
to mark the exit connection as closed, we'd try to remove it from the
pending queue anyway, and hit an assert. Now, we put failed-resolve
connections in a separate state so that mark_for_close does the right
thing.
svn:r1196
who wants to shut down a connection calls connection_mark_for_close instead
of setting marked_for_close to 1. This automatically removes the connection
from the DNS cache if needed, sends a RELAY END cell if appropriate, and can
be changed to do whatever else is needed.
Still to do:
- The same for circuits, maybe.
- Add some kind of hold_connection_open_until_flushed flag, maybe.
- Change stuff that closes connections with return -1 to use mark_for_close,
maybe.
svn:r1145
add some more data to be flushed but never turn POLLOUT on. not sure
how commonly this bug was hit, but it would be a doozy.
Also add some asserts to see if it happens elsewhere.
svn:r1142
arrives, then the stream wasn't getting removed from the pending list.
this may have been the lucky-bug.
this commit may also not actually fix the bug. it's darn hard to
reproduce.
svn:r1122
