svn:r51

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:r49

svn:r48

svn:r47

svn:r46

svn:r45

removed loglevel from global namespace. severity level is set using log() with a NULL format argument now. example: log(LOG_ERR,NULL);


svn:r44

svn:r43

svn:r42

svn:r41

svn:r40

this was another bug i introduced with the 5 july patch.
i should look at that patch more closely. :)


svn:r39

i'm going to take a shower, and then solve the deadlocking problem mat found


svn:r38

svn:r37

svn:r36

Bugfix : connection_exit_process_data_cell() quit after receiving the SS, without waiting for the destination addr/port


svn:r35

svn:r34

svn:r33

svn:r32

svn:r31

basically, a twin is a router which is different except it shares
the same keypair. so in cases where we want to find a "next router"
and all we really care is that it can decrypt the next onion layer,
then a twin is just as good.

we still need to decide how to mark twins in the routerinfo_t and in
the routers config file.


svn:r30

svn:r29

svn:r28

svn:r27

svn:r26

svn:r25

builds now that i've removed common/onion.[ch] (oops)


svn:r24

svn:r23

The 'or' process can now be told (by the global_role variable) what
roles this server should play -- connect to all ORs, listen for ORs,
listen for OPs, listen for APs, or any combination.

* everything in /src/op/ is now obsolete.
* connection_ap.c now handles all interactions with application proxies
* "port" is now or_port, op_port, ap_port. But routers are still always
  referenced (say, in conn_get_by_addr_port()) by addr / or_port. We
  should make routers.c actually read these new ports (currently I've
  kludged it so op_port = or_port+10, ap_port=or_port+20)
* circuits currently know if they're at the beginning of the path because
  circ->cpath is set. They use this instead for crypts (both ways),
  if it's set.
* I still obey the "send a 0 back to the AP when you're ready" protocol,
  but I think we should phase it out. I can simply not read from the AP
  socket until I'm ready.

I need to do a lot of cleanup work here, but the code appears to work, so
now's a good time for a checkin.


svn:r22

they're now in or/onion.c


svn:r21

also, it now sets the listening socket option SO_REUSEADDR


svn:r20

Note that there are new keywords in these, etc. Matej, would you be
interested in going through and patching routers.c, config.c, etc, so
they're cleaner?


svn:r19

(starting to debug my OP integration)


svn:r18

general cleanup, particularly in buffers.c


svn:r17

svn:r16

It should be all you need to do to get working Makefiles on your
platform, whatever your platform is. :)

Let me know if it doesn't generate Makefiles for you. There will still
be some bugs to work out in detecting openssl correctly, in checking for
only the right header files, etc. But we're on our way.


svn:r15

svn:r14

svn:r13

The summary here is that I'm requiring all developers to have
auto* (aclocal, autoconf, automake) installed on their machine.

Since different versions of auto* generate vastly different output,
I'm going to leave its output out of the repository. This means that
whenever you check out a repository, you need to run auto* to generate
a configure file, then run ./configure to get a Makefile, then build.

If you don't have auto* and can't get it, let me know (and I'll try to
convince you to develop on moria).

The benefit here is that while developers have a bit more work to keep
things straight, we can build snapshots that will install just about
anywhere (once we make configure.in work, that is ;)


svn:r12