Re: [Help-gnunet] email-like service atop of GNUnet?

[Ivan Shmakov]

>>>>> Christian Grothoff <address@hidden> writes:
>>>>> On 10/20/2012 05:58 PM, Ivan Shmakov wrote:

[…]

 >> As per [1], my understanding is that the underlying P2P protocol is
 >> provided by libgnunetcore.  The routing (that allows for the
 >> “distant” peers to be connected) is then the responsibility of MESH.
 >> Which, in turn, is used to implement DHT and the filesharing
 >> facility, though I fail to understand their relation to one another.
 >> And, as it seems, the only definitive source on their operation is,
 >> well, the source.

 > Not quite.  It would be more accurate to say that MESH is build on
 > top of the DHT, and the DHT sits on top of CORE.

        Then, I guess, the interaction between the DHT and MESH
        components should be trickier than that, as I've got an
        impression that DHT itself requires access to non-neighbors?

 > And yes, as MESH is still under very active development, there is not
 > much documentation on it.  Work-in-progress ;-).

        ACK.

 >> One valid point from SecuShare, though, is that we may (in certain
 >> situations) benefit from a “simpler” infrastructure.  Which makes me
 >> wonder, what is the purpose of the multitude of daemons GNUnet
 >> currently relies upon?  And what would be the implications of having
 >> an occasionally-run, and perhaps one-binary, GNUnet filesharing
 >> application?  (AIUI, such an application is possible, given that the
 >> most part of GNUnet is implemented within a set of libraries.)

 > Having many processes allows us to isolate problems and manage
 > concurrency without locking.

        ?  I don't seem to understand.  Be it multiple processes, or be
        it threads, as soon as there is a shared resource, locking is
        unavoidable.  To avoid locking, one gets rid of data sharing,
        not introduces processes.

 > And actually, the libraries you're talking about typically contain
 > very little of the actual logic, most of it is in the services (the
 > 'daemons' you're talking about).

        ACK.  What was the rationale behind such a design choice, BTW?

 > Aside from that, I don't think it should make any difference for a
 > normal user if we have one process or a dozen in terms of making it
 > "simpler".

        … Well, yes, unless we're talking about certain proprietary
        platforms, where “one binary that does it all” may be more
        convenient to use (and, say, carry on USB Flash.)  FWIW, PuTTY
        provides a good example of such a convenient tool.

-- 
FSF associate member #7257