The good news is that we're gaining stability. Nonetheless, I've introduced a new flow-control algorithm called "swift" (which I had thought through beforehand, it's not like I improvised it).
This mode kicks in after 30 seconds spent in regular flow-control. It then removes all the queries from the queue (except ours). Then, every 20 seconds, it wakes up and looks at how far we are to clear the flow-control condition, using the present TX rate, estimates how much data it needs to remove from the queue, and proceeds to remove query hits... Those 30/20 seconds apply to UP<->UP connections only, and are 210/140 for leaf nodes. It's really efficient to remove clogging on UP connections and restore a more timely flow of messages. The bad news is that there are memory leaks that I can't chase because dmalloc does not report anything and valgrind is too slow to run on my 2.8 GHz P4... But I have a feeling the leak is not in the core, but rather is a consequence of the recent additions from Emile le Vivre on the GUI side, although I can't prove it. The REALLY bad news is that I won't release 0.93.3 under this memleak condition, so we need to find it. I'll need your help. - (2004.01.12 - RAM) * Display the amount of file descriptors currently used for banning. * New property "banned_count". * Default number of node connections raised to 12 now that many servents support high outdegree. * Don't ping all our neighbours on pong-cache expiration: only select 20% of them, randomly, with at least 3 being selected. * (event.c) Fixed free(0) call and switched to walloc() for subscriber allocation. * Must use file_fopen_missing() when reading the pid file. * New flow-control mode called "swift" mode, shown with an 'S' instead of 'F'. This mode is activated when we have spent some time in flow-control and need to flush the queue faster, at the price of dropping more messages, and possibly some query hits. * Changed minimum for "node_tx_flowc_timeout" to 90 secs (was 60 secs) since new "swift" mode needs at least 70 secs to clear the FC condition with 95% probability. Raphael ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
