[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gnunet] Discouraging results
From: |
Christian Grothoff |
Subject: |
Re: [Help-gnunet] Discouraging results |
Date: |
Thu, 4 Nov 2004 00:42:29 -0500 |
User-agent: |
KMail/1.7 |
On Wednesday 03 November 2004 17:17, John E. Kreznar wrote:
> Christian Grothoff <address@hidden> writes:
> > So either you have some really rare configuration (non-i386
> > architecture, gcc-3.5 :-) ...
>
> That machine is a Pentium 166. It has gcc 2.95.4 installed, but the
> gnunet and libextractor are from pre-compiled Debian packages.
>
> > ... or broken hardware (memory being my favourite; did you run
> > memcheck/memtest anytime in the last 2 months? do other programs
> > crash in funny ways, too?).
>
> Hmm. Actually, there were some "memory events" caused by attempts a
> couple of weeks ago to run a configuration of gnunet which was grossly
> out-sized for that 16 MB machine. These were manifested by messages
> like
>
> Oct 17 18:52:24 iflig kernel: __alloc_pages: 0-order allocation failed
> (gfp=0x1d2/0) Oct 17 18:52:24 iflig kernel: VM: killing process gnunetd
>
> So this idea is worth pursuing. Thanks.
In that case, I would also specifically check the integrity of the swap space
on disc (I'm not sure how, one way might be to disable swap and if gnunetd
then works -- hoping that you're not running out of memory), you found the
problem. This is of course all based on speculation, but assuming you're not
"usually" using that much memory on the machine, it's not completely
unlikely.
> > > Could not bind to port 2087. Is gnunetd running?
> > > Oct 31 23:32:44 'bind' failed at gnunet-check.c:1029 with error:
> > > Address already in use Oct 31 23:32:44 Failure at logging.c:297.
> > > Aborted
> >
> > Well, RTFM: do not run gnunet-check together with gnunetd (see: bind
> > failed).
>
> Actually, man gnunet-check mentions no such restriction. I
> interpreted the bind failure as a failed attempt by gnunet-check to
> connect to gnunetd. I even confirmed with netstat -l that there was a
> listener on port 2087.
Listener! Exactly, gnunet-check internally "emulates" being a little gnunetd,
but it does not try to connect to 2087, it tries to "provide" it (but only as
a way to re-use code from gnunet-insert internally). But you were right, the
manpage did not mention the restriction. Sorry for RTFM'ing you -- and it's
fixed now (in the man page).
> However, this may all be moot. It begins to appear that GNUnet was
> never intended as an alternative to anonymous remailers, nym servers,
> web-to-mail gateways, and postings to alt.anonymous.messages for
> purposes such as anonymous web surfing. What is a good paper that
> gives an overview of GNUnet's goals and means?
I'm afraid I can't point you to just one paper that gives an overview and
would be reasonably accurate at this moment. The webpage probably lacks a
good overview, too, going too much into details. And yes, I should fix that,
too. To answer your question, I would dare to suggest you (for now) the
research papers from http://ovmj.org/GNUnet/papers.php3. You might just read
the introduction to see what they are each about. A good order is probably
ercs.ps, followed by aff.ps, then ebe.ps and finally transport.ps (all from
ovmj.org/GNUnet/downlodad/XXX.ps).
To answer your specific question, yes and no. In the sense of another way to
achieve anonymous communication, GNUnet is intended as an alternative to
anonymous remailers and the like. But a primary difference is that there is
no gateway to traditional services (in your examples http, mail and news).
The general view is that it is better to integrate this kind of functionality
tightly into the system and distribute it inside the peer-to-peer network.
One of the big benefits is that you do not have exit problems, but there are
many other advantages (and disadvantages) to this approach.
Now, GNUnet is _also_ intended to be a peer-to-peer framework. That is, aside
from specific applications that are implemented the way we see fit, it should
be possible to implement other peer-to-peer protocols on top of the basic
code. So if you wanted to implement some other kind of anonymous mixing
system on top of GNUnet and to use it as an anonymizing layer on top of
existing protocols you could do it with GNUnet, but this is not what people
have been working on so far.
I hope this answers your question.
Christian