seeks-users — User forum

Re: [Seeks-users] [BUG] Compilation with latest git Seeks failed

[Bastien <bas...@wi...>]

Heya,

Emmanuel Benazera <ebe...@se...> writes:

> Somehow, this problem has been solved by packagers building an AUR package
> for ArchLinux: http://aur.archlinux.org/packages.php?ID=38053 (beware as this
> seems to be an old release of Seeks).

I just failed to compile seeks from AUR, but it's my fault: not enough
disk space available (uh!)

> To do this packagers did not request any change on Seeks side. Therefore I'd suggest
> you take a look at the work they did to solve this issue. If you believe this should
> require changes within Seeks codebase, please let us know.

Whatever the distro, Seeks codebase should compile fine or warn the
user about missing dependancies (if that's the problem at hand with 
the error log I just send.)

-- 
 Bastien

Re: [Seeks-users] Not easy to find how to make a bug report

[Camille H. <mam...@yo...>]

Le 22/02/2011 18:10, Emmanuel Benazera a écrit :
> I would favor a user space such as a forum where the problems could be exposed.

I'm pretty sure that there is a Wordpress plugin for forums, if you want
I can do this. But maybe a Redmine forum would be better integrated with
bugs.

C.

Re: [Seeks-users] Not easy to find how to make a bug report

[Emmanuel B. <ebe...@se...>]

Hey Bastien,

Thanks for taking the time of reporting these issues.

Having an easier / faster way of reporting bugs would be a plus.

After discussion with other developpers on IRC, it seems that the redmine
will remain as it is, requiring registration. The reason is that many reported
'bugs' are not. Mostly they are configuration problems.

I would favor a user space such as a forum where the problems could be exposed.
When issues are true bugs and recognized as such by developpers, they'd make it
to the redmine. A contributor suggested to use a sub-project to the existing 
redmine for this purpose. This redmine project would be open with no registration
required. After discussion / review, 'true' bugs would be simply 'moved' to the 
main development redmine project.

Note that as of today no user has been denied a registration to the main development
redmine project.

Let us know what you think of the solution above,

Em.

On Sun, Feb 20, 2011 at 12:17:31PM +0100, Bastien wrote:
> Hi there,
> 
> it's not easy to discover how to make a bug report.
> 
> 1. I went on the webpage, searched "bug", found the link at the bottom,
>    followed it, then had to follow another link to the redmine... which
>    doesn't let me report anything.  Room for improvement:
> 
>    1) don't burry the "bug" link
>    2) link it to something one can use *directly*
> 
>    E.g. http://redmine.seeks-project.info/projects/seeks/issues/new
>    rather than http://redmine.seeks-project.info/projects/seeks/issues/
> 
> 2. The README advertizes http://.../projects/seeks/issues/new but one
>    cannot submit an issue until registered (!)
> 
> Let's make it more easy to report bugs!
> 
> (Actually, I'm now using this list for archive purposes, but I'm unsure
> whether it's the right place for such consideration -- let me know.)
> 
> Best,
> 
> -- 
>  Bastien

Re: [Seeks-users] [BUG] Compilation with latest git Seeks failed

[Emmanuel B. <ebe...@se...>]

Hi Bastien,

As far as I remember this problem has been reported before by users of ArchLinux.

Somehow, this problem has been solved by packagers building an AUR package
for ArchLinux: http://aur.archlinux.org/packages.php?ID=38053 (beware as this
seems to be an old release of Seeks).

To do this packagers did not request any change on Seeks side. Therefore I'd suggest
you take a look at the work they did to solve this issue. If you believe this should
require changes within Seeks codebase, please let us know.

Sincerely,

Em.

On Sun, Feb 20, 2011 at 12:09:03PM +0100, Bastien wrote:
> Hi there,
> 
> I just tried to compile after a git pull.
> 
> It fails with this error:
> 
> ,----
> | make  all-recursive
> | make[1]: entrant dans le répertoire « /home/guerry/install/git/seeks »
> | Making all in src
> | make[2]: entrant dans le répertoire « /home/guerry/install/git/seeks/src »
> | Making all in utils
> | make[3]: entrant dans le répertoire « /home/guerry/install/git/seeks/src/utils »
> | Making all in .
> | make[4]: entrant dans le répertoire « /home/guerry/install/git/seeks/src/utils »
> | /bin/sh ../../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I../..  -Wall -Wno-deprecated -g -pipe -I. -I./../proxy -I./../lsh -I./../dht    -g -O2 -MT miscutil.lo -MD -MP -MF .deps/miscutil.Tpo -c -o miscutil.lo miscutil.cpp
> | mv -f .deps/miscutil.Tpo .deps/miscutil.Plo
> | mv: impossible d'évaluer « .deps/miscutil.Tpo »: Aucun fichier ou dossier de ce type
> | make[4]: *** [miscutil.lo] Erreur 1
> | make[4]: quittant le répertoire « /home/guerry/install/git/seeks/src/utils »
> | make[3]: *** [all-recursive] Erreur 1
> | make[3]: quittant le répertoire « /home/guerry/install/git/seeks/src/utils »
> | make[2]: *** [all-recursive] Erreur 1
> | make[2]: quittant le répertoire « /home/guerry/install/git/seeks/src »
> | make[1]: *** [all-recursive] Erreur 1
> | make[1]: quittant le répertoire « /home/guerry/install/git/seeks »
> | make: *** [all] Erreur 2
> `----
> 
> I attach the config.log.
> 


> 
> -- 
>  Bastien

[Seeks-users] Not easy to find how to make a bug report

[Bastien <bas...@wi...>]

Hi there,

it's not easy to discover how to make a bug report.

1. I went on the webpage, searched "bug", found the link at the bottom,
   followed it, then had to follow another link to the redmine... which
   doesn't let me report anything.  Room for improvement:

   1) don't burry the "bug" link
   2) link it to something one can use *directly*

   E.g. http://redmine.seeks-project.info/projects/seeks/issues/new
   rather than http://redmine.seeks-project.info/projects/seeks/issues/

2. The README advertizes http://.../projects/seeks/issues/new but one
   cannot submit an issue until registered (!)

Let's make it more easy to report bugs!

(Actually, I'm now using this list for archive purposes, but I'm unsure
whether it's the right place for such consideration -- let me know.)

Best,

-- 
 Bastien

[Seeks-users] [BUG] Compilation with latest git Seeks failed

[Bastien <bas...@wi...>]

Hi there,

I just tried to compile after a git pull.

It fails with this error:

,----
| make  all-recursive
| make[1]: entrant dans le répertoire « /home/guerry/install/git/seeks »
| Making all in src
| make[2]: entrant dans le répertoire « /home/guerry/install/git/seeks/src »
| Making all in utils
| make[3]: entrant dans le répertoire « /home/guerry/install/git/seeks/src/utils »
| Making all in .
| make[4]: entrant dans le répertoire « /home/guerry/install/git/seeks/src/utils »
| /bin/sh ../../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I../..  -Wall -Wno-deprecated -g -pipe -I. -I./../proxy -I./../lsh -I./../dht    -g -O2 -MT miscutil.lo -MD -MP -MF .deps/miscutil.Tpo -c -o miscutil.lo miscutil.cpp
| mv -f .deps/miscutil.Tpo .deps/miscutil.Plo
| mv: impossible d'évaluer « .deps/miscutil.Tpo »: Aucun fichier ou dossier de ce type
| make[4]: *** [miscutil.lo] Erreur 1
| make[4]: quittant le répertoire « /home/guerry/install/git/seeks/src/utils »
| make[3]: *** [all-recursive] Erreur 1
| make[3]: quittant le répertoire « /home/guerry/install/git/seeks/src/utils »
| make[2]: *** [all-recursive] Erreur 1
| make[2]: quittant le répertoire « /home/guerry/install/git/seeks/src »
| make[1]: *** [all-recursive] Erreur 1
| make[1]: quittant le répertoire « /home/guerry/install/git/seeks »
| make: *** [all] Erreur 2
`----

I attach the config.log.

[Seeks-users] Fwd: Re: snippet = de formulaire de recherche

[Camille H. <mam...@yo...>]

Hi all, here is an idea, it's in French, sorry. I'll translate it later,
this post is just to archive.

C.

-------- Message original --------
Sujet: Re: snippet = de formulaire de recherche
Date : Wed, 16 Feb 2011 09:37:48 +0100
De : Emmanuel Benazera <ebe...@se...>
Pour : Camille Harang <mam...@yo...>
Copie à : loic.dachary Loic Dachary <lo...@da...>

Salut,

cool, est-ce que tu pourrais plutôt poster cette idée sur la mailing list
stp, pour générer de la discussion ?

Em.sx

On Wed, Feb 16, 2011 at 10:42:21AM +0100, Camille Harang wrote:
> Yo, une petite idée come ça à chaud tant que j'y pense : permettre la
> définition de gabarits de formulaires de recherche dans les snippets.
> 
> Par exemple je tape "ajax django" on devrait me renvoyer un snippet avec
> de pages parlant d'ajax et django. L'idée ce serait aussi de permettre à
> ces snippets de contenir la définition d'un formulaire de recherche sur
> un autre site, par exemple on répondrait :
> 
> "Tu veux des trucs qui parlent d'ajax et django ? Beh t'as qu'a taper
> 'ajax' dans ce formulaire couillon :
> http://docs.djangoproject.com/en/1.2/search/". En langage ordinateur
> hein, du coup le client seeks retape le mot clef et merge les résultats.
> 
> Comme ça plutôt que les Apaches génèrent des snippets et des mots clefs
> pour contenu de leurs sites comme c'est prévu à terme, il balancent
> simplement leur formulaire de recherche. Du coup on aurait le matching
> exact dans la BD du site sans crawler. Vous en pensez quoi ? C'est un
> peu comme les plugins actuels RSS/twitter actuels, mais dynamiques et
> généralisables, ça peut être chaud à parser, mais avec quelques parseurs
> génrique (genre sorties RSS, wordpress, etc.) et un flag dans le snippet
> pour avertir du format de la sortie ça peut ratisser. Genre pour la
> requête "beniz l'esplanade" le contenu d'un snippet pourrait être :
> 
> form: http://membres.lesplanade.org/search
> method: post
> q_field: search-submit
> output: wordpress
> 
> Après on peut imaginer un langage de parsing (si ça existe pas déjà) et
> fournir les infos de parsing dans le snippet.
> 
> Voilà, c'était pour les archives, si ça vous évoque des idées dites moi :-)
> 
> Adistahz,
> 
> Camille.
> 
> -- 
> The Good, the Bad and the Ugly under Creative Commons!
> https://yooook.net/r/lp1

Re: [Seeks-users] P2P Network and Software Security Method

[Emmanuel B. <ebe...@se...>]

Hi,

sorry for the delay in the answer.

Seeks needs to protect both data and people.

On the data front:
1a- queries should be protected as much as possible on the network.
1b- local (personal) data such as ratings and URIs, should be
  protected from phishing and eavesdropping.
1c- data should be served from identified / secure sources, avoiding
  man-in-the-middle type of attacks.

On the people front:
2a- people's identity on the network should be protected.
2b- association of query and people should be made difficult.

There may be other situations to take into account. Most of these issues
are challenging because Seeks' aim is to have people collaborate through
an intense exchange of data fragments.

Some of the issues above are already taken into account in Seeks' design.
Thus 1a is made easier because Seeks exchanges queries in the form of 
hashed query fragments. This is similar to content encryption. It is even
slightly more robust since the breaking into fragments allows to partially
fulfill 2b: Seeks makes it very difficult, if not impossible to infer the 
_exact_ query sent by a user.
1b is very partially fulfilled as data transits in the form of compressed
protocol buffers. Adding encryption is required for true protection though.

The path to a very secured application is likely to be long. I am interested
in listing technical solutions for all the issues above.

Em.

On Sun, Jan 23, 2011 at 03:58:06PM +0100, Alexandre CABROL PERALES wrote:
> This topic is already opened.
> But i would like to relocate this discussion.
> 
> Before start to define how to protect an information system we have
> to talk about:
> * which method we will use to secure the system
> * what is the scope
> * what is the risk assesment
> 
> More over technical solutions are not enougth.
> 
> I can take as example Tor project which has to practice awareness on
> usage of it's network. Tor main security issue is social engineering
> like phishing.
> 

[Seeks-users] Summary of architecture meeting (2010-01-19)

[Emmanuel B. <ebe...@se...>]

Hi all,

Below, a summary of the architecture meeting that took place last week.

Em.

[Seeks-users] P2P Network and Software Security Method

[Alexandre C. P. <ale...@la...>]

This topic is already opened.
But i would like to relocate this discussion.

Before start to define how to protect an information system we have to 
talk about:
* which method we will use to secure the system
* what is the scope
* what is the risk assesment

More over technical solutions are not enougth.

I can take as example Tor project which has to practice awareness on 
usage of it's network. Tor main security issue is social engineering 
like phishing.

Re: [Seeks-users] Pros and Cons of using IPSec for DHT routing and P2P transport ?

[Alexandre C. P. <ale...@la...>]

You will find here french presentation about network tunneling and 
detection.

http://www.hsc.fr/ressources/presentations/sstic06/SSTIC06_Tunnels_Lehembre_Thivillon-1.1.pdf


Le 23/01/2011 15:45, Alexandre CABROL PERALES a écrit :
> Full comparison between ssl and ipsec from International Association
> for Cryptologic Research
>
> http://eprint.iacr.org/2004/314.pdf
>
>
> Le 23/01/2011 15:32, Alexandre CABROL PERALES a écrit :
>> Tor uses TLS for encryption.
>> http://www.torproject.org/docs/faq.html.en#KeyManagement
>>
>>
>>
>> Le 23/01/2011 15:21, Alexandre CABROL PERALES a écrit :
>>> From my point of view,
>>> i think it would be better to use ssl instead of IPSec.
>>>
>>> For indirect technical reason.
>>>
>>> First of all IPSec is designed to connect ip network (like wan) and not
>>> for application dial.
>>>
>>> More over SSL/TLS is well known and used for Software to Software secure
>>> dial.
>>>
>>> I will conclude by the fact that SSL is recognized on 443 port as https
>>> which usually is an easy way to pass-through firewalls and proxies.
>>>
>>>
>>> So to be able to reach the most possible nodes i would recommend ssl.
>>>
>>>
>>>
>>> Le 23/01/2011 11:10, Emmanuel Benazera a écrit :
>>>>
>>>> Hi,
>>>>
>>>> I'm not familiar with IPSec (http://en.wikipedia.org/wiki/IPsec) yet.
>>>> I'm wondering
>>>> whether IPSec could be used for certification / authentification of
>>>> DHT nodes,
>>>> as well as for P2P connections among users (for exchanging URLs,
>>>> appreciations, queries) ?
>>>>
>>>> Any thoughts on these issues ?
>>>>
>>>> Thanks,
>>>>
>>>> Em.
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>>>> Finally, a world-class log management solution at an even better
>>>> price-free!
>>>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>>>> February 28th, so secure your free ArcSight Logger TODAY!
>>>> http://p.sf.net/sfu/arcsight-sfd2d
>>>> _______________________________________________
>>>> Seeks-users mailing list
>>>> See...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/seeks-users
>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>>> Finally, a world-class log management solution at an even better
>>> price-free!
>>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>>> February 28th, so secure your free ArcSight Logger TODAY!
>>> http://p.sf.net/sfu/arcsight-sfd2d
>>>
>>>
>>>
>>> _______________________________________________
>>> Seeks-users mailing list
>>> See...@li...
>>> https://lists.sourceforge.net/lists/listinfo/seeks-users
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better
>> price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>>
>>
>>
>> _______________________________________________
>> Seeks-users mailing list
>> See...@li...
>> https://lists.sourceforge.net/lists/listinfo/seeks-users
>
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
>
>
>
> _______________________________________________
> Seeks-users mailing list
> See...@li...
> https://lists.sourceforge.net/lists/listinfo/seeks-users

Re: [Seeks-users] Pros and Cons of using IPSec for DHT routing and P2P transport ?

[Alexandre C. P. <ale...@la...>]

Full comparison between ssl and ipsec from International Association
for Cryptologic Research

http://eprint.iacr.org/2004/314.pdf


Le 23/01/2011 15:32, Alexandre CABROL PERALES a écrit :
> Tor uses TLS for encryption.
> http://www.torproject.org/docs/faq.html.en#KeyManagement
>
>
>
> Le 23/01/2011 15:21, Alexandre CABROL PERALES a écrit :
>> From my point of view,
>> i think it would be better to use ssl instead of IPSec.
>>
>> For indirect technical reason.
>>
>> First of all IPSec is designed to connect ip network (like wan) and not
>> for application dial.
>>
>> More over SSL/TLS is well known and used for Software to Software secure
>> dial.
>>
>> I will conclude by the fact that SSL is recognized on 443 port as https
>> which usually is an easy way to pass-through firewalls and proxies.
>>
>>
>> So to be able to reach the most possible nodes i would recommend ssl.
>>
>>
>>
>> Le 23/01/2011 11:10, Emmanuel Benazera a écrit :
>>>
>>> Hi,
>>>
>>> I'm not familiar with IPSec (http://en.wikipedia.org/wiki/IPsec) yet.
>>> I'm wondering
>>> whether IPSec could be used for certification / authentification of
>>> DHT nodes,
>>> as well as for P2P connections among users (for exchanging URLs,
>>> appreciations, queries) ?
>>>
>>> Any thoughts on these issues ?
>>>
>>> Thanks,
>>>
>>> Em.
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>>> Finally, a world-class log management solution at an even better
>>> price-free!
>>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>>> February 28th, so secure your free ArcSight Logger TODAY!
>>> http://p.sf.net/sfu/arcsight-sfd2d
>>> _______________________________________________
>>> Seeks-users mailing list
>>> See...@li...
>>> https://lists.sourceforge.net/lists/listinfo/seeks-users
>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better
>> price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>>
>>
>>
>> _______________________________________________
>> Seeks-users mailing list
>> See...@li...
>> https://lists.sourceforge.net/lists/listinfo/seeks-users
>
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
>
>
>
> _______________________________________________
> Seeks-users mailing list
> See...@li...
> https://lists.sourceforge.net/lists/listinfo/seeks-users

Re: [Seeks-users] Pros and Cons of using IPSec for DHT routing and P2P transport ?

[Alexandre C. P. <ale...@la...>]

Tor uses TLS for encryption.
http://www.torproject.org/docs/faq.html.en#KeyManagement



Le 23/01/2011 15:21, Alexandre CABROL PERALES a écrit :
>  From my point of view,
> i think it would be better to use ssl instead of IPSec.
>
> For indirect technical reason.
>
> First of all IPSec is designed to connect ip network (like wan) and not
> for application dial.
>
> More over SSL/TLS is well known and used for Software to Software secure
> dial.
>
> I will conclude by the fact that SSL is recognized on 443 port as https
> which usually is an easy way to pass-through firewalls and proxies.
>
>
> So to be able to reach the most possible nodes i would recommend ssl.
>
>
>
> Le 23/01/2011 11:10, Emmanuel Benazera a écrit :
>>
>> Hi,
>>
>> I'm not familiar with IPSec (http://en.wikipedia.org/wiki/IPsec) yet.
>> I'm wondering
>> whether IPSec could be used for certification / authentification of
>> DHT nodes,
>> as well as for P2P connections among users (for exchanging URLs,
>> appreciations, queries) ?
>>
>> Any thoughts on these issues ?
>>
>> Thanks,
>>
>> Em.
>>
>> ------------------------------------------------------------------------------
>>
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better
>> price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> Seeks-users mailing list
>> See...@li...
>> https://lists.sourceforge.net/lists/listinfo/seeks-users
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
>
>
>
> _______________________________________________
> Seeks-users mailing list
> See...@li...
> https://lists.sourceforge.net/lists/listinfo/seeks-users

[Seeks-users] Network Evading

[Alexandre C. P. <ale...@la...>]

I will open a topic introduced by Beniz's question about which 
encryption network to use.

Which is: what is best way for network evading?

You can find interesting discussion on this list:
http://lists.zooko.com/pipermail/p2p-hackers/2011-January/002766.html

Today most of computers are behind NAT, Proxy, Firewall.

Those security and network tools are real trouble for P2P node's 
connections.

Maybe we could discuss this point to identify best ways for network
evading.

Skype and Tor have made deep work on this topic.

Re: [Seeks-users] Pros and Cons of using IPSec for DHT routing and P2P transport ?

[Alexandre C. P. <ale...@la...>]

 From my point of view,
i think it would be better to use ssl instead of IPSec.

For indirect technical reason.

First of all IPSec is designed to connect ip network (like wan) and not 
for application dial.

More over SSL/TLS is well known and used for Software to Software secure 
dial.

I will conclude by the fact that SSL is recognized on 443 port as https 
which usually is an easy way to pass-through firewalls and proxies.


So to be able to reach the most possible nodes i would recommend ssl.



Le 23/01/2011 11:10, Emmanuel Benazera a écrit :
>
> Hi,
>
> I'm not familiar with IPSec (http://en.wikipedia.org/wiki/IPsec) yet. I'm wondering
> whether IPSec could be used for certification / authentification of DHT nodes,
> as well as for P2P connections among users (for exchanging URLs, appreciations, queries) ?
>
> Any thoughts on these issues ?
>
> Thanks,
>
> Em.
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Seeks-users mailing list
> See...@li...
> https://lists.sourceforge.net/lists/listinfo/seeks-users
>
>

[Seeks-users] Pros and Cons of using IPSec for DHT routing and P2P transport ?

[Emmanuel B. <ebe...@se...>]

Hi,

I'm not familiar with IPSec (http://en.wikipedia.org/wiki/IPsec) yet. I'm wondering
whether IPSec could be used for certification / authentification of DHT nodes,
as well as for P2P connections among users (for exchanging URLs, appreciations, queries) ?

Any thoughts on these issues ?

Thanks,

Em.

Re: [Seeks-users] DHT: blocking vs non-blocking

[Emmanuel B. <ebe...@se...>]

On Mon, Jan 17, 2011 at 12:21:16AM +0100, Loic Dachary wrote:
> On 01/16/2011 10:34 AM, Emmanuel Benazera wrote:
> > Hi Loic,
> >
> > in my opinion, non-blocking I/O allow for better performance, especially
> > on DHT nodes supporting a few hundreds of virtual nodes.
> >
> >   
> I don't see any reason to run a DHT with more than 32 virtual nodes (the
> default). If more virtual nodes are needed for some reason, it's
> straightforward to run more processes on the same machine. Say you want
> 320 virtual nodes, you can just run 10 processes and I don't see why it
> would be significantly less efficient than running one process with 320
> virtual nodes.

Running processes would not allow the 320 nodes to use the same communication
port as far as I understand.
 
> Could you be more specific about why you think it would be bad for
> performances to have blocking I/O ?
> > The reason I see is that in blocking mode the stabilizer iterates among
> > elements to stabilize (finger table, successors). Thus every blocking
> > operation delays the whole queue of waiting elements.
> >   
> Yes. But if you want to accelerate the stabilisation for some reason
> (although I can't see any at the moment), you can add threads to the
> stabilisation (it currently only has one). For instance you could run 4
> threads, each responsible for 40 entries in each finger table (the
> stabilisation of a finger table entry involves a run of find_successor
> which is by far the longest blocking operation of the stabilization
> process).

My understanding is that theoretically stabilization should be constant or at
least bounded in time. Practically this means that a node should fix a broken
successor in less than x seconds or milliseconds, x being the same constant 
for every DHT node.
It seems to me that the blocking IO model makes x dependent on the number of
virtual nodes hosted on the DHT node.

Em.

Re: [Seeks-users] deferred C++

[Loic D. <lo...@da...>]

On 01/17/2011 10:45 AM, Jamu Kakar wrote:
> Hi Loic,
>
> On Mon, Jan 17, 2011 at 10:31 AM, Loic Dachary <lo...@da...> wrote:
>   
>>> Cool, it's great to hear that it's useful/interesting. :) Out of
>>> curiousity, what are you planning to do to it?  I've got a branch with
>>> some basic work in place to add cancellation support... I've also been
>>> thinking about extracting it from ion (which is a sort of playground
>>> for C++ for me) and making it a standalone library.
>>>       
>> The seeks DHT is going to use libevent and non blocking I/O. The main
>> use of the deferred will be to attach them to a file descriptor
>> expecting an incoming message. I would like to start by copying your
>> code in the seeks tree and write a few unit tests to get to know your
>> implementation better. I see that you are using boost and I will also
>> need to remove this dependency. Do you have any advice related to this ?
>>
>> I don't think I'll need features beyond the basics any time soon. A
>> robust implementation is what I'm looking for, even if it means it's not
>> feature rich.
>>     
> Ah, I see, sounds interesting.  The addition of boost is relatively
> new... you may want to look at r41 in lp:ion.  It's the revision in
> which I introduced Boost.  Before that I used hand-rolled code, which
> might be easier for you to extract.
>
> Also, note that there are unit tests for Deferred in Ion, so you
> should be able to learn something from them (of course, nothing
> replaces trying things yourself and getting your hands dirty).
>
> Thanks,
> J.
>
>   
Hi,

I re-implemented something from scratch. My primary reason was that I
could impose strong assumptions on the application code. My
implementation lacks genericity compared to yours. It is specialized.
The algorithm of the main callback loop is almost exactly the same as
twisted.

Cheers

Re: [Seeks-users] deferred C++

[Jamu K. <jk...@ka...>]

Hi Loic,

On Mon, Jan 17, 2011 at 10:31 AM, Loic Dachary <lo...@da...> wrote:
>> Cool, it's great to hear that it's useful/interesting. :) Out of
>> curiousity, what are you planning to do to it?  I've got a branch with
>> some basic work in place to add cancellation support... I've also been
>> thinking about extracting it from ion (which is a sort of playground
>> for C++ for me) and making it a standalone library.
>
> The seeks DHT is going to use libevent and non blocking I/O. The main
> use of the deferred will be to attach them to a file descriptor
> expecting an incoming message. I would like to start by copying your
> code in the seeks tree and write a few unit tests to get to know your
> implementation better. I see that you are using boost and I will also
> need to remove this dependency. Do you have any advice related to this ?
>
> I don't think I'll need features beyond the basics any time soon. A
> robust implementation is what I'm looking for, even if it means it's not
> feature rich.

Ah, I see, sounds interesting.  The addition of boost is relatively
new... you may want to look at r41 in lp:ion.  It's the revision in
which I introduced Boost.  Before that I used hand-rolled code, which
might be easier for you to extract.

Also, note that there are unit tests for Deferred in Ion, so you
should be able to learn something from them (of course, nothing
replaces trying things yourself and getting your hands dirty).

Thanks,
J.

Re: [Seeks-users] deferred C++

[Loic D. <lo...@da...>]

> Cool, it's great to hear that it's useful/interesting. :) Out of
> curiousity, what are you planning to do to it?  I've got a branch with
> some basic work in place to add cancellation support... I've also been
> thinking about extracting it from ion (which is a sort of playground
> for C++ for me) and making it a standalone library.
>
>   
The seeks DHT is going to use libevent and non blocking I/O. The main
use of the deferred will be to attach them to a file descriptor
expecting an incoming message. I would like to start by copying your
code in the seeks tree and write a few unit tests to get to know your
implementation better. I see that you are using boost and I will also
need to remove this dependency. Do you have any advice related to this ?

I don't think I'll need features beyond the basics any time soon. A
robust implementation is what I'm looking for, even if it means it's not
feature rich.
> Anyway, I'm very glad to hear you're thinking about using it.  If you
> have questions or problems please let me know, I'll be happy to help.
>   
This is very generous of you, thank you :-)

Cheers

Re: [Seeks-users] deferred C++

[Jamu K. <jk...@ka...>]

Hi Loic,

On Mon, Jan 17, 2011 at 8:13 AM, Loic Dachary <lo...@da...> wrote:
> As part of my involvement in the http://seeks-project.info/ software, I
> will be working with and possibly improve the deferred implementation
> you wrote for https://edge.launchpad.net/ion
>
> I would very much appreciate your input before I proceed with the code
> found in the main branch.
>
> Thanks for providing this base :-)

Cool, it's great to hear that it's useful/interesting. :) Out of
curiousity, what are you planning to do to it?  I've got a branch with
some basic work in place to add cancellation support... I've also been
thinking about extracting it from ion (which is a sort of playground
for C++ for me) and making it a standalone library.

Anyway, I'm very glad to hear you're thinking about using it.  If you
have questions or problems please let me know, I'll be happy to help.

Thanks,
J.

[Seeks-users] deferred C++

[Loic D. <lo...@da...>]

Hi,

As part of my involvement in the http://seeks-project.info/ software, I
will be working with and possibly improve the deferred implementation
you wrote for https://edge.launchpad.net/ion

I would very much appreciate your input before I proceed with the code
found in the main branch.

Thanks for providing this base :-)

Re: [Seeks-users] DHT: blocking vs non-blocking

[Loic D. <lo...@da...>]

On 01/16/2011 10:34 AM, Emmanuel Benazera wrote:
> Hi Loic,
>
> in my opinion, non-blocking I/O allow for better performance, especially
> on DHT nodes supporting a few hundreds of virtual nodes.
>
>   
I don't see any reason to run a DHT with more than 32 virtual nodes (the
default). If more virtual nodes are needed for some reason, it's
straightforward to run more processes on the same machine. Say you want
320 virtual nodes, you can just run 10 processes and I don't see why it
would be significantly less efficient than running one process with 320
virtual nodes.

Could you be more specific about why you think it would be bad for
performances to have blocking I/O ?
> The reason I see is that in blocking mode the stabilizer iterates among
> elements to stabilize (finger table, successors). Thus every blocking
> operation delays the whole queue of waiting elements.
>   
Yes. But if you want to accelerate the stabilisation for some reason
(although I can't see any at the moment), you can add threads to the
stabilisation (it currently only has one). For instance you could run 4
threads, each responsible for 40 entries in each finger table (the
stabilisation of a finger table entry involves a run of find_successor
which is by far the longest blocking operation of the stabilization
process).
> Also, from what I understand modern DHT such as 'maidsafe' are event-based.
>
>   
It is aso my intuition : event based in more hype than multi-thread
nowadays. I'm sensitive to this trend although it's hardly based on pure
logic ;-)
> Now, how do we get there, to the non-blocking I/O ? What I see are many
> changes to the DHT. Do we have a working (or almost) working blocking 
> design right now ? If yes, I would propose we go with it and review
> the operations before moving ahead with non-blocking. Typically there 
> are potential bugs that I see in the (old) 'dht' branch that need to be 
> discussed.
>   
We're already in the middle of a massive change and going for
non-blocking has a fundamental impact on the code.
> If no, I'd say we go straight for the non-blocking I/O, not waiting 
> 'en route'.
>   
I don't believe a switch from blocking to non blocking can happen
without breaking everything.
> Typically, could you give an estimate of the design & development time 
> needed in both cases ?
>
>   
No I can't. I thought I could a week ago but that was without the time
spent on evaluating the blocking / non blocking impact on the design. In
a nutshell, I will start to be able to estimate how long it will take
after a week of coding without facing significant architectural challenges.
> Thanks for the clear exposure of both architectures. Personnally I don't
> find the non-blocking I/O code to be much more difficult to read than
> the blocking one.
>   
I suspect you will be reminded this statement a couple of times in the
future ;-)

I should add that I did not make up this coding style. It is practiced
by applications using the deferred design pattern. I would be
unconfortable inventing a coding style or a design pattern in the
context of the implementation of the DHT.

Cheers

Re: [Seeks-users] DHT: blocking vs non-blocking

[Emmanuel B. <ebe...@se...>]

Hi Loic,

in my opinion, non-blocking I/O allow for better performance, especially
on DHT nodes supporting a few hundreds of virtual nodes.

The reason I see is that in blocking mode the stabilizer iterates among
elements to stabilize (finger table, successors). Thus every blocking
operation delays the whole queue of waiting elements.
Also, from what I understand modern DHT such as 'maidsafe' are event-based.

Now, how do we get there, to the non-blocking I/O ? What I see are many
changes to the DHT. Do we have a working (or almost) working blocking 
design right now ? If yes, I would propose we go with it and review
the operations before moving ahead with non-blocking. Typically there 
are potential bugs that I see in the (old) 'dht' branch that need to be 
discussed.
If no, I'd say we go straight for the non-blocking I/O, not waiting 
'en route'.

Typically, could you give an estimate of the design & development time 
needed in both cases ?

Thanks for the clear exposure of both architectures. Personnally I don't
find the non-blocking I/O code to be much more difficult to read than
the blocking one.

thanks for the good work!

Em.

On Sun, Jan 16, 2011 at 01:03:11AM +0100, Loic Dachary wrote:
> Hi,
> 
> After discussing the pros and cons of using blocking I/O versus
> non-blocking I/O for the implementation of the DHT, it boils down to the
> following:
> 
>     blocking => trivial implementation but threads
>     non blocking => single thread but deferred style implementation
> 
> After reviewing other aspects (performances, scaling, resource usages,
> complexity of the dependencies and more) I did not find any with a
> significant influence, either on the maintainability or on the usability.
> 
> As a friend suggested tonight, when there is no compelling reason to
> chose one solution over the other, start a 60 seconds countdown and
> decide when it expires. Unless anyone has a particular insight to share
> with me, it's what I'm going to do on Monday ;-)
> 
> Cheers
> 
> * blocking vs non blocking
> 
>   The chord algorithms are documented as if I/O were blocking.
>   Iteratively finding the successor for a key is a loop
>   using nodes retrieved closer and closer to the key.
> 
>     node = self.closest_predecessor(key)
>     until(key in [node,successor[)
>        node, successor = node.closest_predecessor(key)
> 
>   With non blocking I/O and deferred
>   ( http://en.wikipedia.org/wiki/Workflow_patterns#State-based_patterns )
>   it could be:
> 
>   function find_successor(searched_key)
> 
>     function find_successor(predecessor, successor)
>         if(searched_key in [predecessor, successor[)
>           return successor    node = self.closest_predecessor(key)
> 
>         else
>           deferred = predecessor.send(find_closest_predecessor)
>           deferred.addCalback(closest_predecessor)
>           return deferred
> 
>     function closest_predecessor(predecessor)
>         deferred = predecessor.send(get_successor)
>         deferred.addCalback(lambda successor:
> find_successor(predecessor, successor))
>         return deferred
> 
>     node = self.closest_predecessor(key)
>     deferred = node.send(get_successor)
>     deferred.addCallback(lambda successor: find_successor(node, successor))
>     return deferred
> 
>   function my_function(successor)
>      ... do my stuff ...
> 
>   find_successor(key).addCallback(my_function)
> 
>   The downside of the non blocking approach shows : the implementation
> is more
>   complex and significantly harder to read.
> 
>   The upside is that there is no need to isolate every call to
>   find_successor in a separate thread. Even in moderately large Chord
>   rings, a find_successor involving 5 nodes with a RTT of 100ms on
>   average would takes 5 * 100 * 2 = 1 second (the 2 is for successor +
>   find_closest_predecessor).
> 

> begin:vcard
> fn:Loic Dachary
> n:Dachary;Loic
> org:pokersource
> adr:;;12 bd Magenta;Paris;;75010;France
> email;internet:lo...@da...
> title:Senior Developer
> tel;work:+33 4 84 25 08 05
> tel;home:+33 9 51 18 43 38
> tel;cell:+33 6 64 03 29 07
> note:Born 131414404 before EPOCH.
> x-mozilla-html:FALSE
> url:http://dachary.org/
> version:2.1
> end:vcard
> 




> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl

> _______________________________________________
> Seeks-users mailing list
> See...@li...
> https://lists.sourceforge.net/lists/listinfo/seeks-users

[Seeks-users] DHT: blocking vs non-blocking

[Loic D. <lo...@da...>]

Hi,

After discussing the pros and cons of using blocking I/O versus
non-blocking I/O for the implementation of the DHT, it boils down to the
following:

    blocking => trivial implementation but threads
    non blocking => single thread but deferred style implementation

After reviewing other aspects (performances, scaling, resource usages,
complexity of the dependencies and more) I did not find any with a
significant influence, either on the maintainability or on the usability.

As a friend suggested tonight, when there is no compelling reason to
chose one solution over the other, start a 60 seconds countdown and
decide when it expires. Unless anyone has a particular insight to share
with me, it's what I'm going to do on Monday ;-)

Cheers

* blocking vs non blocking

  The chord algorithms are documented as if I/O were blocking.
  Iteratively finding the successor for a key is a loop
  using nodes retrieved closer and closer to the key.

    node = self.closest_predecessor(key)
    until(key in [node,successor[)
       node, successor = node.closest_predecessor(key)

  With non blocking I/O and deferred
  ( http://en.wikipedia.org/wiki/Workflow_patterns#State-based_patterns )
  it could be:

  function find_successor(searched_key)

    function find_successor(predecessor, successor)
        if(searched_key in [predecessor, successor[)
          return successor    node = self.closest_predecessor(key)

        else
          deferred = predecessor.send(find_closest_predecessor)
          deferred.addCalback(closest_predecessor)
          return deferred

    function closest_predecessor(predecessor)
        deferred = predecessor.send(get_successor)
        deferred.addCalback(lambda successor:
find_successor(predecessor, successor))
        return deferred

    node = self.closest_predecessor(key)
    deferred = node.send(get_successor)
    deferred.addCallback(lambda successor: find_successor(node, successor))
    return deferred

  function my_function(successor)
     ... do my stuff ...

  find_successor(key).addCallback(my_function)

  The downside of the non blocking approach shows : the implementation
is more
  complex and significantly harder to read.

  The upside is that there is no need to isolate every call to
  find_successor in a separate thread. Even in moderately large Chord
  rings, a find_successor involving 5 nodes with a RTT of 100ms on
  average would takes 5 * 100 * 2 = 1 second (the 2 is for successor +
  find_closest_predecessor).