help-gnunet
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]