Bottom line: When the expected time to complete a transfer is larger than the expected time before the node is taken down, then that node could just as well stay down permanently. All of the output bandwidth it is consuming is going to be wasted when none of the zillion transfers finish.
I think things are looking up. Backoff on QR's is helping. I think backoff is not optimum, but it's working now and improving it is not the top priority. I like overload message which answers all outstanding and future queries until overload cleared message gives a token to put into new requests to distinguish them from stale requests. (After all, I proposed it...) Tom K's idea about FIFO/LIFO request queue is interesting too. But I don't think it matters much how this is done now. (So long as backoff isn't circumvented when a node leaves the RT and quickly returns). Instead, we need to get routing working well. I claim big routing tables will help that. At least, we should try it. Can anyone tell me why big routing tables won't help routing? --- digression ---- I thought of an argument in favor of exponential backoff: it randomly (real not pseudo randomness) picks requester peers and essentially bans them (or they ban themselves). This is what we want: a node with limited bandwidth should be accepting requests from a limited number of other nodes. The rest of the nodes need to route around that one. The nodes which happened to receive 4 or 5 QR's in a row will replace the backed-off node with a different one in their routing table. --- end digression --- I think the next important problem is eliminating huge backlogs. Fixing it is easy: QR when the expected backlog duration is over a configurable parameter, say 1 hour. Given QR backoff and QR when backlog is hig, it should be possible to run with a huge routing table. It is my (current) opinion that say 300 nodes in the RT, 1200 open connections, could help routing a lot: with more choices, a node can route around congestion easily. I think I will try that again and see what happens. Last time I tried, I got huge localQueryTraffic. But with QR backoff working, and with backoff surviving removal from routing table, I shouldn't see that. -- Ed Huff
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
