[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap

From: Ludovic Courtès
Subject: Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap
Date: Thu, 13 Mar 2014 00:15:38 +0100
User-agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux)

Sree Harsha Totakura <address@hidden> skribis:

> On 03/12/2014 09:56 PM, Ludovic Courtès wrote:
>>>> Let's just stick with the GNUnet server (we call such a server
>>>> as a service in GNUnet, let's call it Guix service) as of now.
>>>> HTTP can be done optionally.  Moreover the currently binary
>>>> distribution is made through a HTTP server.
>> Yeah, let’s keep HTTP optional.  The requirement will be to have a
>> server over GNUnet’s MESH, right?
> Yes, so the service should be using both DHT and MESH services of
> GNUnet.  DHT to publish and lookup packages and MESH for downloading
> and seeding packages.



>>>> The requirements from Guix side are missing here.  IMO, you
>>>> have to: * Understand the current protocol used over HTTP to
>>>> search and download packages from Guix Hydra server. *
>>>> Implement a equivalent client/downloader in Guix using Guile
>>>> to download the packages using GNUnet. * Extend the Guix daemon
>>>> to publish package updates into GNUnet DHT, whenever new
>>>> packages are added to the Guix store.
>> I think guix-daemon would remain unchanged.  Instead, the package
>> publisher could (say) periodically ask for the list of live store
>> items (as per ‘guix gc --list-live’) and publish those.
> OK, I agree; this is also simple.  Does '--list-live' option list all
> the items in the store or only the ones currently used?

It lists the items that cannot be garbage-collected because they are
referenced from a GC root (indirectly.)

> I believe it is helpful for other peers to push all items in the
> store, but then how do packages age-out?

When the garbage collector runs, some of the items that were previously
available may have disappeared.  Thus, they must not longer be
advertised in the DHT.

>> However, I think the protocol could be different from, and simpler
>> than Hydra’s.
>> Ideally, I imagine you could do something like:
>> dht-get /gnu/store/ykmg6ydrmlkn600wklriw3wzc1z3dcli-emacs-24.3
>> and get as a reply (roughly) a tuple containing:
>> 1. a signature (as a canonical s-expression);
>> 2. a reference to a MESH channel from which to download the archive
>> of that store item;
> We also need a peer identity in the tuple since establishing MESH
> connections require both the peer identity and a channel number.  MESH
> is the GNUnet's equivalent of TCP: peer identity ~= IP address;
> channel number ~= port number.

Yes, sure.

Is it possible to have several values associated with a key in the DHT?

I’m asking because here we’d need to have the ability to get zero or
more tuples as described above, one tuple for each node that claims to
publish /gnu/store/ykmg6ydrmlkn600wklriw3wzc1z3dcli-emacs-24.3.


reply via email to

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