gnunet-developers
[Top][All Lists]
Advanced

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

RE: [GNUnet-developers] vsftpd/wget/gnunet


From: Jan Marco Alkema
Subject: RE: [GNUnet-developers] vsftpd/wget/gnunet
Date: Tue, 31 Dec 2002 09:47:14 -0800

Hello Igor,

>In addition you should perhaps study gnunet design and the way we block and
use data in AFS, I'm not certain if you understand that.

I have a dilemma. If you study the current implementation too much in detail
I will be narrowed in mine points of view. First "say what you what" and
later see if it is in the current implementation.

>If you can, in terms of algorithms and their complexity - or some
published, serious empirical results - make a convincing argument
on the lines of "indexing algorithm A in dbmgr X is better than
algorithm B in gdbm because..." and references, that would probably
be a good start to turn our heads.

>Till then, there is no point continuing this discussion on
just feeling-based grounds.

On the date 14-10-2002 I have looked a little bit at the implementation of
gnunet. Trying to fix the "scanDirectory bug". I saw that the host directory
is searched every few seconds on a linear manner. Yesterday I had 201 key in
the hosts directory. I don't not know what proof you want but I think as
hosts key will rise indexing (and binary search) is always better. See also
Appendix A: "Lineair searching of hosts in gnunet".

address@hidden hosts]# ls -la|wc -l
    201
address@hidden hosts]#

Dec 31 12:47:21 DEBUG: scanning directory /usr/local/gnunet/var/data/hosts/
for peer identity
Dec 31 12:47:23 DEBUG: scanning directory /usr/local/gnunet/var/data/hosts/
for peer identity
.
.
Dec 31 12:47:25 DEBUG: scanning directory /usr/local/gnunet/var/data/hosts/
for peer identity
Dec 31 12:47:26 DEBUG: scanning directory /usr/local/gnunet/var/data/hosts/
for peer identity

>Well, we shall see whether there will ever be even 1000 gnunet
host keys. :) Besides, I've a feeling the current gnunet routing
can't manage nearly the scale you suggest, so that would have
to be solved first. :(

A year ago I have installed a gnutella client (gnut) on mine computer. I
believe as I remember that I got a 2000 Ip addresses in the "host catcher"
in a few day. After a week a had 8000 ip addresses. N.B. I known that Ip
addresses can be DHCP like, but there were a lot of cable/Adsl servers
("fixed" ip addresses).

>If, in your opinion, the whole our current way of handling files is bad,
you should state that clearly and present alternatives and convincing
argument for them.

I don't say that "current way of handling files is bad". Only I miss the
flexibility in different purposes of gnunet. Some files I want to encrypted
and other files may every one have. N.B. I don't want to use gnunet and ftp.
In mine point of view Ftp should be incorporated in gnunet in some efficient
way.

>> I don't see the advances of the bloom filter yet?

>Its quite transparent. Perhaps we should collect some statistics
about its operation.

I think that a (MD5 and file size) on a total file is enough for me. You can
easy see if you have the file locally. I will look to the statistics what
"the gain for me" --).

I see that inserting of big files takes a lot of time. No discussion on
just feeling-based grounds! All I want to say that for a certain purpose it
could be a good argument. For other purposes it is very inefficient. It is
the opportunity to find out on which case you should use which part of the
implementation.

>You might be interested in a project called "mldonkey" which was
recently brought to my attention.

Thank you for the suggestion of mldonkey ---),

Greetings Jan Marco

Appendix A: Lineair searching of hosts in gnunet:

directory1=/usr/local/fsh/gnunet/var/data/hosts/!
name1=F3C5AA9C8BB59DC6729D94CD45C610F6A2C8B810.6!dirname=/usr/local/fsh/gnun
et/var/data/hosts/!
name1=F3C5AA9C8BB59DC6729D94CD45C610F6A2C8B810.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=B2DF03C35AD3CFC3EF95BCF662C6C4120EEB7CB9.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=82AAB7539C7789B11BC222F015BFC066A9C7A0E2.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=82AAB7539C7789B11BC222F015BFC066A9C7A0E2.6!dirname=/usr/local/fsh/gnun
et/var/data/hosts/!
name1=CB1DA8BDE93876472E0C57700EFDB84CAD8C7908.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=2AA027B590707A3F9DC2FAFDFDB45080873CF6B6.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=6F541E02F1B8E63D719EDAA846CC8DC72B3E731B.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=955AA4FFF0AF98301DC4BF6E55F62030B2F6B358.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=F0A9EE62A63D59956947EAE8F694996759712B73.6!dirname=/usr/local/fsh/gnun
et/var/data/hosts/!
name1=FA6159AF874AA18E834052848BF5AECD32612699.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=DBEFF9DE830D4D143DC98627A02E84D119A4EC60.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=5CE33ABC28AC28631D7E1441960BC1329BDD7A3C.17!
.
.
dirname=/usr/local/fsh/gnunet/var/data/hosts/!
name1=52EEA409A9F6BA98FF024C8FE557B1DFE4E8D291.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=BF80CDDA0649B7EED0B3A40DE811DB5DB077109A.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=6A2CE2DE44BAC91E66E63382ACDDA7849010D0A8.6!dirname=/usr/local/fsh/gnun
et/var/data/hosts/!
name1=2DF0894268C997E9635027F7EEFC55097140021C.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=955AA4FFF0AF98301DC4BF6E55F62030B2F6B358.6!dirname=/usr/local/fsh/gnun
et/var/data/hosts/!
name1=C76CC40E1C70229CAEF48A96282A623D28A575D6.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=0716EB2B33A85E1A5B2B3968A5FBA20AA582E3A0.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=F02C765BD8DCA989D72E02ABC9D9852FD4DC111D.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!
name1=8EA9EC740BF7F7398D05E92344471C3B1380D66A.6!dirname=/usr/local/fsh/gnun
et/var/data/hosts/!
name1=459D4D3A7A7EAA14FF24186F7184CB777F6D0214.17!dirname=/usr/local/fsh/gnu
net/var/data/hosts/!




reply via email to

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