| Commit message (Collapse) | Author | Age |
|
|
|
| |
svn:r173
|
|
|
|
| |
svn:r172
|
|
|
|
| |
svn:r170
|
|
|
|
|
|
|
|
| |
thanks nick :)
(note: this change breaks backward compatibility)
svn:r169
|
|
|
|
| |
svn:r167
|
|
|
|
| |
svn:r166
|
|
|
|
| |
svn:r164
|
|
|
|
|
|
|
| |
one to stop reading
svn:r163
|
|
|
|
| |
svn:r162
|
|
|
|
| |
svn:r161
|
|
|
|
| |
svn:r160
|
|
|
|
| |
svn:r159
|
|
|
|
|
|
|
| |
serious performance increase over non-caching
svn:r158
|
|
|
|
| |
svn:r157
|
|
|
|
| |
svn:r156
|
|
|
|
|
|
|
|
|
| |
(they wouldn't have before)
alternate code which bypasses the dns farm, so we can compare speed
svn:r154
|
|
|
|
|
|
|
| |
performance is better, but not by much. not sure why yet.
svn:r153
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
taken from openbsd
svn:r151
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
svn:r149
|
|
|
|
|
|
|
|
| |
(amazing the odd behavior you get to test when you have a flaky modem
connection)
svn:r148
|
|
|
|
|
|
|
|
| |
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:r144
|
|
|
|
| |
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
|
|
|
|
| |
svn:r141
|
|
|
|
| |
svn:r140
|
|
|
|
| |
svn:r139
|
|
|
|
| |
svn:r138
|
|
|
|
|
|
|
| |
first cut, probably needs more playing with
svn:r137
|
|
|
|
|
|
|
| |
reformat parts of onion.c
svn:r136
|
|
|
|
|
|
|
|
|
| |
If you weren't connected to a given router, and you made a directory
request to it simultaneously with a new web query that caused you to
want to connect to that OR... it would think you're already connected.
svn:r135
|
|
|
|
|
|
|
| |
don't list non-open ORs in the directory
svn:r134
|
|
|
|
| |
svn:r133
|
|
|
|
| |
svn:r132
|
|
|
|
|
|
| |
clean up error handling in onion.c
svn:r131
|
|
|
|
| |
svn:r130
|
|
|
|
| |
svn:r129
|
|
|
|
| |
svn:r126
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
(text that it spits out immediately upon connect)
svn:r124
|
|
|
|
| |
svn:r123
|
|
|
|
| |
svn:r122
|
|
|
|
| |
svn:r121
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
tor can now interface directly with mozilla, as a socks 4 host.
but note that mozilla does the dns resolution itself, so you're leaking
anonymity.
svn:r119
|
|
|
|
| |
svn:r118
|
|
|
|
| |
svn:r117
|