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.
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
need to be throttleable as bandwidth currently is. (The same applies
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?
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?
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."
This seems implacably hostile to using dyndns to point to a freenet
node! By its nature a freenet node makes it difficult but not
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
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.
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
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
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
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
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."
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
_______________________________________________
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
