On Fri, Jan 16, 2004 at 02:30:53AM -0500, Paul Derbyshire wrote: > You may remember me as the one who had problems with fproxy that > proved to be brain-dead IE defaults. Turns out fproxy and my node are > working fine, and the node gets around 1 request a second suggesting > it's integrating way better than the freesite of evil keeps bitching > about. :) > > Reachability of stuff browsed through the interface seems to improve > as it gels into the network. > > Then this AM there was an incident, which happened to catch me in > front of the keyboard. It was hard not to notice, since the whole > system became largely unresponsive. For whatever reason, my node had > spawned over 5000 new threads in a matter of seconds and bloated to > take up much more RAM and most of the CPU, forcing me to restart the > service from the tray menu. Hopefully enough is cached between > sessions that this won't seriously compromise the node's integration.
Yeah, this is a problem. There is a solution, we are not sure whether it is ready to be made the default yet though. It may however be ready. This is caused by a very large number of very short lived tasks suddenly getting executed; this can happen for lots of reasons... > > I have a number of new questions, none of which the FAQ will answer. > 1. What caused this? I've heard of some versions grabbing a lot of > system resources when inserting certain kinds of keys locally through > FCP, but not spontaneously or as a result of requests. Can it happen > when some kinds of keys are inserted by just propagating to your > node? Was it trying to upload and store a large file, maybe one that > came in 5000 asynchronous fragments? Pathological behavior that > cripples the host system until the node is restarted manually, > possibly then hurting the network by interrupting what would have > been an important task for others or by setting back the "integration > clock" on your node is, IMO, bad. Thread, CPU, and memory use may Well, it should probably settle eventually... > need to be throttleable as bandwidth currently is. (The same applies Okay, individually: Thread usage - possible, using YThreadFactory and tfAbsoluteMaxThreads. Hopefully we can merge this code soon. Involves some delay to tasks, and if we are unlucky there could be some problems. CPU usage - very, VERY hard to do, because java cannot tell us what the current CPU usage is in a portable manner. However messageSendTimeRequest, which we use in the load calculation, is a pretty good indicator, as is routingTime. If these are too high we reject incoming queries, so there is long-term control of CPU usage. Note that your operating system provides utilities to make Freenet the lowest priority application on the system - nice on unix, on windoze 2000, NT, go to task manager and right click on the process running freenet (java.exe?), and set the priority level. Memory usage - harder than CPU usage probably. We know how much memory is used, but there is no certainty that it will decrease if we let things stew for a while... also, we cannot generally recover from out of memory i.e. allocation failures, and to do so a LOT of code would need to be rewritten. All these should be reduced by profile directed optimization - and multiplexing, merged in 5053, should reduce CPU usage in particular by a large margin. > double to the gnutella client I run, though, which frequently bloats > up to 2000 threads and uses way more ram than the freenet node under > normal circumstances -- i.e. normal for the node AND the gnutella > client. :)) > 2. Is this already addressed by the update? > 3. How do you install the update, short of opening Explorer and > painstakingly navigating your way to the Freenet install directory > under Program Files to run the updater? Update is a logical item for > the tray menu on Win32, but it's not there; failing that it's a > logical button for the configure tool's main tab, but it's not there > either. [While on the subject, the configure tool needs a cooler name > and a cross-platform rather than MFC implementation. I suggest a > lightweight C++/GTK app and a name of FreeConfigurator. :)] > 4. My machine seems to get a new IP address every so often, > automagically, and not just after a reboot. How well will the node > handle that?: > a. Will it start screwing up if the IP changes mid-session and have > to be manually restarted? How to detect this or better yet, automate > it? Short of restarting it on a fixed schedule, which would probably > be bad. Or will it discover the new ip for itself? Perhaps as long as > it works OK without uncommenting and changing the ipAddress line in > freenet.ini it will cope automatically? No, it will detect the change. > b. How bad an effect on the network will the dynamic IP have, > especially if it requires periodic node restarts beyond the usual > "Windows had a cerebral embolism in its atrophied and still largely > 16-bit brain; time to reboot again, sigh" situations? Not too bad. The network will either pick up your ARK, or it won't; if it doesn't, they'll just use other nodes, and your node will have to reannounce... > I'd rather avoid the dyndns.org service that I was shocked to find > pimped in a comment in the configuration file. Shocked, because of > this from its Click-through Terms of Service Of The Week(tm by > Microsoft who pioneered the practise): > > "The Member will not use the Service for illegal software, junk > pornography, spamming or any use of distribution lists to any person > who has not given specific permission to be included in such a > process. The Member agrees not to transmit through the service any > unlawful, harassing, libelous, abusive, threatening, harmful, > vulgar, obscene or otherwise objectionable material of any kind or > nature...The Member further agrees not to transmit any material that > encourages conduct that could constitute a criminal offense, give > rise to civil liability or otherwise violate any applicable local, > state, national, or international law or regulation." :) Nothing like a good bit of covering one's posterior from legal attacks. > > This seems implacably hostile to using dyndns to point to a freenet > node! By its nature a freenet node makes it difficult but not Perhaps so. You think they'd sue you for running a freenet node? The RIAA etc wouldn't, because they are not the aggreived party. But IANAL. > impossible for its operator to know what is being "transmitted > through the service", and impossible for the operator to control it. > Of course, it's hard to prove that "junk pornography" (and just how > in the hell is that defined, and why does dyndns take it upon itself > to dictate sexual mores like it was some 19th century church?) and so > on is really in your store, but the node operator is put in an > uncomfortable position. If they truly honor the above agreement > rather than ignoring it, they must use all means at their disposal to > at least try to determine and control what flows through their node > and resides in it! Also, this is technically possible. If they ignore Doesn't your ISP have a similar requirement? Mine does, and I suspect every ISP in the western world does. And that is far more dangerous than dyndns. > the above agreement, freenet does provide some shield of "plausible > deniability", which if employed will just make dyndns explicitly > outlaw use of freenet in combination with its service, once they > check the web page to find out what all the hoopla is about and > realize that freenet's philosophy and architecture and their own > policy are inherently at odds. I doubt it. They wouldn't add a clause to ban freenet, unless not doing so would be dangerous. This is not about what they give a sh*t about, it's about eliminating liability. But IANAL. > > Getting away with it is probably feasible for the time being. When > freenet becomes less obscure however we'll probably see a mass move > by services like this (which I suspect must be run by nuns and > priests seeking an alternative revenue stream since the flow of > indulgences dried up -- this isn't the only service I've seen that > explicitly states that its users must be neuter, like androids or > worker bees, or else do a darn good job of pretending they are) to No. This has nothing to do with morality and everything to do with avoiding legal liability. That's why your ISP's terms and conditions probably include almost identical wording. If they are sued, they can say that what you did with their service was against their AUP, which you have read. That absolves them of responsibility for it. Or some such cr*p. > simply explicitly refuse use of the service in connection with > freenet. Or rather whatever an attorney of law (probably one > practising somewhere in close proximity to the Holy See, at that) > overgeneralizes from it, say "you agree not to use this service in > connection with any service, software, system, remote cousin, borg > drone, or starship that may enable encrypted storage of or anonymous > transmission of information by you or any third parties, where 'in > connection with' includes using our service to gateway to the I doubt such things will happen until a general legal ban on anonymous filesharing is imminent. > anonymizing and/or encrypted storage service, running something > vaguely connected with ours and something vaguely connected with the > anonymizing and/or encrypted storage service on the same machine or > on different machines reachable in a common address space on a Wide > Area Network (WAN), or mentioning either service en passant whilst > using the other or whilst someone who shares more than 75% of your > RFLP DNA fingerprints uses the other. In short, we reserve the right :) IIRC, linking to sites that link to illegal material is illegal in the USA, based on 2600 (Corely) vs MPAA (Universal et al). :) > to explicitly and directly interfere with any ports, introduce any > proxies, and randomly terminate the service of anyone so as to > prevent someone using evil peer to peer software anywhere on the > internet, especially if it affords a) anonymity or b) an encrypted > store, for fear that either someone will rip off the RIAA, which You don't think your ISP would dump you the moment they got a nasty looking letter from the MPAA? How much more so dyndns, which has a negligible interest in any given customer. > coincidentally is one of our major advertising partners, or else > possibly be titillated, amused, aroused, or have some kind of actual > fun whilst connected via our service. We reserve the right to change > the service at any time, and the terms of service, and in fact plan > to block everything but port 80 next > upgrade whilst requiring users to wear an elaborate patented device > that > combines the functions of a copyright-protecting dongle and a > chastity belt." :) Watch this space - many ISPs and far too many universities have this policy. :( > > Reductio ad absurdum, but there's a lot of that slippery slope ahead > before most people will notice the absurdity, at which point the > (lack of) coefficient of dynamic friction will do the rest. :P -- 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
