Re: [freenet-support] Stable build 5069
FYI the seednodes.ref in snapshots is not viable for 5069. I tried reseeding during the upgrade, but it looks like the file only contains one complete node reference, and it was skipped as bad by 5069. -s On Sun, 15 Feb 2004 01:08:54 + Toad <[EMAIL PROTECTED]> wrote: > Freenet stable build 5069 is now available. The snapshots will have been > updated sometime in the next few minutes; if you don't get 5069, try > again in an hour's time. If it's still 5068, complain to > [EMAIL PROTECTED] You can get it via the update.sh script on > Linux, BSD, or OS/X, or use the freenet-webinstall.exe utility to update > on Windows, or get the jar from > http://freenetproject.org/snapshots/freenet-latest.jar . All stable > branch users should upgrade. > > A large number of bugfixes, some of them major, and a number of larger > changes, are present in this build. Details: > * Fixed a major bug in stats that was causing us to dramatically > underestimate our used bandwidth resulting in effectively no controls on > the number of trailers transferring, resulting in too many requests > accepted, too many parallel transfers, and most of them running really > slowly and eventually failing. > * Fixed another major bug that resulted in one request for a reasonably > available file causing a large number of transfers; certain send > failure modes were not being handled properly, with the result that we > continued to receive the file (thus allowing it to propagate through > the network), but forgetting about it so that when it does complete, > it does not get committed, and moving on to request the file from > another node, so we end up transferring many copies, most of which end > up in the temp dir and never leave it; this bug wasted a lot of > bandwidth and also disk space. > * Implemented new rate limiting algorithm. Joint effort by me and ian. > Should be much better behaved than the old one, involves less > "alchemy". Each node we are connected to is sent a different minimum > request interval, depending on how many requests it makes, but all > have a reasonably fair quota, which will increase quickly if needed. > This data is included on the Open Connections page at max detail. > * Lots of improvements and bugfixes to the rate limiting system: all FNP > messages now carry the request interval, and we can read it from > IdentifyPacketMessage's (although we don't write it yet). The code to > detect nodes violating the minimum request intervals has been > significantly improved, and we now have a message so that nodes can > tell other nodes that they have violated their quota, with some > debugging info. However this is not necessarily all wrapped up yet. > When it is, we will implement some enforcement mechanisms such as > banning nodes which persistently violate the request intervals. > * Many minor optimizations and fixes. > * Opera (the browser) users who have read and acted on the warning, i.e. > configured opera to respect MIME types, can now set > mainport.params.servlet.1.params.dontWarnOperaUsers=true to get rid of > the warning page. > -- > Matthew J Toseland - [EMAIL PROTECTED] > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] number of connections
On Mon, Jan 26, 2004 at 06:32:36AM -0600, Conrad J. Sabatier wrote: > On Sat, Jan 24, 2004 at 11:21:14PM -0800, Steven wrote: > > since multiplexing has been ported to the stable branch of freenet, we can > > have a MUCH lower maxConnection setting right? I used allow 300, now I only > > allow 20. Is this a bad idea? > > 20 connections max is quite low. You have to allow a certain number of > connections for the nodes in your routing table, for one thing. It's a > wonder your node even runs at all. > > Try setting it to something more reasonable, like, say, 128 or 256. You'll > most likely never hit that number with multiplexing, but it's good to allow > the node some breathing room. > > > I've had a lot of traffic on my node, and everything seems to be working fine > > (although connecting initially took forever) according to the numbers, but i > > can't retrieve much. > > >From what I'm reading lately, it seems that content accessibility is > actually better these days with unstable. :-) > > Although, I just noticed someone inserted a new version of their site > ([EMAIL PROTECTED]/Jukebox/6// "The Jukebox of DJ Free") > with a bunch of activelinks added at the bottom that I haven't been able to > retrieve in a very long time. So I'm thinking maybe certain content is only > reachable in one or the other. They are separate networks. Some people, such as the author of TFHI, insert content on both networks at once. But for other stuff, the only way it propagates from one to another is people switching branches and taking their stores with them. > > -- > Conrad Sabatier <[EMAIL PROTECTED]> - "In Unix veritas" -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
[freenet-support] Stable build 5069
Freenet stable build 5069 is now available. The snapshots will have been updated sometime in the next few minutes; if you don't get 5069, try again in an hour's time. If it's still 5068, complain to [EMAIL PROTECTED] You can get it via the update.sh script on Linux, BSD, or OS/X, or use the freenet-webinstall.exe utility to update on Windows, or get the jar from http://freenetproject.org/snapshots/freenet-latest.jar . All stable branch users should upgrade. A large number of bugfixes, some of them major, and a number of larger changes, are present in this build. Details: * Fixed a major bug in stats that was causing us to dramatically underestimate our used bandwidth resulting in effectively no controls on the number of trailers transferring, resulting in too many requests accepted, too many parallel transfers, and most of them running really slowly and eventually failing. * Fixed another major bug that resulted in one request for a reasonably available file causing a large number of transfers; certain send failure modes were not being handled properly, with the result that we continued to receive the file (thus allowing it to propagate through the network), but forgetting about it so that when it does complete, it does not get committed, and moving on to request the file from another node, so we end up transferring many copies, most of which end up in the temp dir and never leave it; this bug wasted a lot of bandwidth and also disk space. * Implemented new rate limiting algorithm. Joint effort by me and ian. Should be much better behaved than the old one, involves less "alchemy". Each node we are connected to is sent a different minimum request interval, depending on how many requests it makes, but all have a reasonably fair quota, which will increase quickly if needed. This data is included on the Open Connections page at max detail. * Lots of improvements and bugfixes to the rate limiting system: all FNP messages now carry the request interval, and we can read it from IdentifyPacketMessage's (although we don't write it yet). The code to detect nodes violating the minimum request intervals has been significantly improved, and we now have a message so that nodes can tell other nodes that they have violated their quota, with some debugging info. However this is not necessarily all wrapped up yet. When it is, we will implement some enforcement mechanisms such as banning nodes which persistently violate the request intervals. * Many minor optimizations and fixes. * Opera (the browser) users who have read and acted on the warning, i.e. configured opera to respect MIME types, can now set mainport.params.servlet.1.params.dontWarnOperaUsers=true to get rid of the warning page. -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] routing table
On Sat, Feb 14, 2004 at 09:34:06AM +0100, Niklas Bergh wrote: > > Is it a VM bug or is it just creating > > objects it theoretically could reach (thus they don't get GC'd), but > > ignores forever? > > The second it what is defined as a 'memory leak' in GC'd environments. Or a "space leak". > > /N -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] routing table
> Is it a VM bug or is it just creating > objects it theoretically could reach (thus they don't get GC'd), but > ignores forever? The second it what is defined as a 'memory leak' in GC'd environments. /N ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
