Igor Wronsky | 1 Aug 2003 01:02
Picon

RE: slocate

On Thu, 31 Jul 2003, jan marco alkema wrote:

> > This was a rather amusing reference to the nature of your posts, which
> has, as you'll recall, often been the subject of some discussion on the
> list.
> Maybe I have a different opinion about sharing things --)
> In my point of view: If you want to spread a system like gnunet with "end
> users" then you should use well known "drivers" for end-users in the Gnunet
> application like ftp, wget, locate, etc.

There seems to be slight communication problems here. To help,
I'll try to summarize the different viewpoints of this and past
discussions as I see them. This naturally is rather subjective
and may not reflect the true views of any person involved
or the goals of the gnunet project.

Basically, what Jan wants is a distributed global
database or filesystem that contains all the information
in the world. This database is built of nodes that
provide different sorts of information. In Jan's scenario,
the owner of the node should be able to specify how
his node is used, who uses it, perhaps ability to set
prices on different services or content provided,
and security/anonymity levels for content. Also, Jan
would want the system to incorporate existing protocols
such as ftp seamlessly, and choose transport mechanism
according to the level of anonymity required either by
the recipient, the content, or the provider, allowing
for maximum efficiency/security tradeoff with minimum
redundancy. Whatever information available should
(Continue reading)

jan marco alkema | 4 Aug 2003 21:28
Picon
Favicon

RE: slocate

Hello Igor,

>Basically, what Jan wants is a distributed global database or filesystem
that contains all the information in the world. This database is built of
nodes that provide different sorts of information. In Jan's scenario, the
owner of the node should be able to specify how his node is used, who uses
it, perhaps ability to set prices on different services or content provided,
and security/anonymity levels for content. Also, Jan would want the system
to incorporate existing protocols such as ftp seamlessly, and choose
transport mechanism according to the level of anonymity required either by
the recipient, the content, or the provider, allowing for maximum
efficiency/security tradeoff with minimum redundancy. Whatever information
available should be easily importable/exportable to/from Jan's system.

You made a perfect description of my ideas. Igor, Thank you for this --)

I will go futher with an "end users" view:

I looked at the GTK GUI of Gnunet. It is easy to use for end users.

The biggest problem I see for Gnunet AFS protocol is the speed of
transferring a file. I have downloaded 3 files and 1 is still in progress
(after 12 hours).  The BPS (bits pro second) in GTK screen are 3.3 ; 12.3 ;
35.7 ; 46.3 !!!!!

Maybe this slow bits rates can be accelerated, but if you want an acceptable
tool you need speed. In my opinion everything what can be shared without
problem should be set to "not AFS", like ftp.

N.B. The slow AFS speed is appropriate for the telephone resolution of
(Continue reading)

Niklas Höglund | 5 Aug 2003 12:56
Picon
Picon
Favicon

Re: slocate

jan marco alkema wrote:

>Hello Igor,
>
>  
>
>>Basically, what Jan wants is a distributed global database or filesystem
>>    
>>
>that contains all the information in the world. This database is built of
>nodes that provide different sorts of information. In Jan's scenario, the
>owner of the node should be able to specify how his node is used, who uses
>it, perhaps ability to set prices on different services or content provided,
>and security/anonymity levels for content. Also, Jan would want the system
>to incorporate existing protocols such as ftp seamlessly, and choose
>transport mechanism according to the level of anonymity required either by
>the recipient, the content, or the provider, allowing for maximum
>efficiency/security tradeoff with minimum redundancy. Whatever information
>available should be easily importable/exportable to/from Jan's system.
>
>You made a perfect description of my ideas. Igor, Thank you for this --)
>
This should probably be built as a separate application on top of  
gnunet, ftp, gnutella, ...

>I will go futher with an "end users" view:
>
>I looked at the GTK GUI of Gnunet. It is easy to use for end users.
>
>The biggest problem I see for Gnunet AFS protocol is the speed of
(Continue reading)

Christian Grothoff | 5 Aug 2003 17:02
Picon
Favicon

Re: slocate


On Monday 04 August 2003 02:28 pm, jan marco alkema wrote:
> I see I have 315622 files on my Linux server.
>
> There are less than 20 files I don't want to share with others, password
> files, ip table files, etc. I have < 5000 files which I only want to share
> with the AFS protocol. That are the java class files of KPN for example.
> For the rest of the files {(315622 - (10 + 5000) ) = 3151612 files} I have
> no problem to use the very fast "ftp method" for sharing these files with
> others on the Internet.

I absolutely agree with this point: for most files that people will want to 
share, AFS is the wrong choice since the cost of anonymity is just not worth 
it. And in fact, I hope to extend GNUnet in the future with an option where 
you can choose for both receiving and sharing files if you want to be 
anonymous or not. There is actually a Mantis bug which naturally leads to 
this: it should be possible to specify the level of anonymity for each shared 
file. Naturally, a plausible choice could be "not anonymous at all", in which 
case GNUnet should switch to a more efficient routing mechanism. The same 
applies for searching and downloading.

But, again, this is a bit further down the road, don't expect this to happen 
this year :-).

Christian
Glenn McGrath | 6 Aug 2003 13:33
Picon

gnunet doesnt build against new libgcrypt

Looks like lots of changes in the new libgcrypt, trying to compile
GNUnet 0.5.4a against it.

warning: `GCRY_SEXP' is deprecated
warning: `GcryMPI' is deprecated
warning: `GcrySexp' is deprecated
error: `GCRYERR_INV_OBJ' undeclared
error: `GCRYERR_NO_OBJ' undeclared
error: too few arguments to function `gcry_mpi_print'
error: too few arguments to function `gcry_mpi_scan'

There is some work to do....

What is the plan with regard to the internal crypto stuff now ?

Glenn
jan marco alkema | 10 Aug 2003 20:57
Picon
Favicon

RE: slocate

Hello Niklas, Christian,

Thank you for your feedback ---)

Niklas, I can see in your feedback that you have experience with file
sharing systems --)

>This should probably be built as a separate application on top of gnunet,
ftp, gnutella, ...

In my opinion the applications gnunet, ftp, gnutella should use the same
MySQL database structure. I prefer that the projects make and maintain the
database interface to this structure. The database structure should be some
kind of rfc???? document.

>I agree that the speed is a problem, but as you say maybe it can be
improved.

I see in the Gnunet documentation a lot of formulas. I like to have some
breakdown in speed bottlenecks of the AFS protocol.

>The problem with protocols like FTP is that when things get overloaded it
doesn't work any longer, while in gnunet the file would be propagated to
other nodes automatically. This could make gnunet faster than FTP.

If a gnunet node gets overloaded you maybe also have a problem. If this node
is a single source all packets must be put on Internet. If 1 block is
missing you haven’t the complete file.

>Just look at what happens in gnutella when many people try to download a
(Continue reading)

Niklas Höglund | 12 Aug 2003 14:56
Picon
Picon
Favicon

Re: slocate

jan marco alkema wrote:

>Hello Niklas, Christian,
>
>Thank you for your feedback ---)
>
>Niklas, I can see in your feedback that you have experience with file
>sharing systems --)
>
>  
>
>>This should probably be built as a separate application on top of gnunet,
>>    
>>
>ftp, gnutella, ...
>
>In my opinion the applications gnunet, ftp, gnutella should use the same
>MySQL database structure. I prefer that the projects make and maintain the
>database interface to this structure. The database structure should be some
>kind of rfc???? document.
>
Different programs need different database structures, because they use 
their data in different ways. In gnunet, all data is stored as encrypted 
1k blocks, while in gnutella entire files are stored unencrypted.

I guess that what you want is a unified way to search all this data. As 
someone wrote here earlier, there are projects to provide a single user 
interface on top of many peer-to-peer systems. I think "gift" is the 
name of one.

(Continue reading)

Toni W Ruottu | 11 Aug 2003 14:40
Picon
Picon
Favicon

giFT-plugin

Have anyone considered writing a giFT plug-in for GNUnet.

There are many p2p sharing networks and all of them have
their ups and downs.

GiFT Internet File Transfer is a centralised daemon that
has support for multiple p2p networks trought plug-ins.
It allows clients to contact to it and perform searches
to all the networks at once and downloading from them as
they were only one network.

The only important feature giFT is still lacking is
support for multiple users on one pc. I hope they are
wise enought to add that feature.

Take a look at...
http://gift.sourceforge.net

Thanks for your time
-- Toni W. Ruottu (a.k.a. Cyberix)
jan marco alkema | 12 Aug 2003 19:39
Picon
Favicon

RE: giFT-plugin

Hello Toni,

I think it is very good to cooperate with other projects --) Very project
has it's specific goals, and should be good in realizing their goals.

My only disadvantage of giFT is that giFT uses GTK, QT, KDE clients. See
also http://gift.sourceforge.net/clients.php

I prefer Java as GUI above GTK, GT, KDE.

If others has better opinions please let me know ---)

Greetings Jan Marco

giFT 0.11.3

-------------------- core ---

giftd...................: yes
libgift.................: yes
libgiftproto............: yes
use ltdl................: yes

-------------- extensions ---

use perl................: no (support temporarily deprecated)

--------- meta data tools ---

use libvorbis...........: yes
(Continue reading)

Igor Wronsky | 13 Aug 2003 11:25
Picon

Re: giFT-plugin

On Mon, 11 Aug 2003, Toni W Ruottu wrote:

> Have anyone considered writing a giFT plug-in for GNUnet.

Easiest way to do that would be to run gnunet daemon
separately and make the giFT plugin out of the
current gnunet client code by combining gnunet-download,
gnunet-search, gnunet-insert and gnunet-delete.

The slight downside of this approach is that giFT can't
then specifically control gnunet bandwidth or know
when another node is downloading something through gnunet.
But taking gnunetd along for modification is certainly
much more work.

One remaining problem is that such a plugin would have
to be constantly maintained as the gnunet protocol
(also the client-server part) may change from
version to another. In the best case the plugin would
be a part of the gnunet source tree.

The bottom line is that it can be done. If there is
anyone motivated in actually doing it is much less
certain.

> The only important feature giFT is still lacking is
> support for multiple users on one pc.

And serious plugins. It seems to me giFT is
lacking a couple of the more recent beasts.
(Continue reading)


Gmane