HACKING now explains bandwidth throttling, congestion control,
and router twins. Read it and see if it makes sense.


svn:r68

svn:r67

svn:r66

svn:r65

svn:r64

svn:r63

svn:r62

Removed more obsolete files


svn:r61

svn:r60

svn:r59

for people wanting to play with the code. the hacking doc is still incomplete.


svn:r58

svn:r57

I modified new_route so we don't pick twins back-to-back in the path.

I also had to patch my previous uses of connection_twin_get_by_addr_port()
because they assumed that "addr" and "port" would be the same for a twin
as for the original router.


svn:r56

svn:r55

Servers are allowed to send 100 cells initially, and can't send more until
they receive a 'sendme' cell from that direction, indicating that they
can send 10 more cells. As it currently stands, the exit node quickly
runs out of window, and sends bursts of 10 whenever a sendme cell gets
to him. This is much much much faster (and more flexible) than the old
"give each circuit 1 kB/s and hope nothing overflows" approach.

Also divided out the connection_watch_events into stop_reading,
start_writing, etc. That way we can control them separately.


svn:r54

we're now much more robust when bandwidth varies: instead of forcing a
fixed bandwidth on the link, we instead use what the link will give us,
up to our bandwidth.


svn:r53

Put in a note in README to explain how to compile (I had to wade
through the cvs messages), and added my router on mosg.cl.cam.ac.uk to
the list of routers.


svn:r52

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