Re: [Sipdht-devel] SIPDHT Experiments

[Adetola O. <ao...@es...>]

Hello All,

I am very aware that you no longer support the first version of sipdht..
But, is it possible that anyone may know how increase the maximum number
of tcp connections in the sipdht version 1, cos at the moment it is
limiting me to just 20 connection after which there is a callback
failure.

Thanks and Regards,

Tola


On Tue, 2008-02-19 at 10:06 +0000, Oredope, Adetola wrote:
> Hello Enrinco,
> 
> Thanks a lot for your help.
> We are considering going back to the first version of SIPDHT (based on
> chord) but I will keep you informed on how it goes.
> 
> Kind Regards,
> 
> Tola
> 
> -----Original Message-----
> From: Enrico Marocco [mailto:enr...@te...] 
> Sent: 18 February 2008 07:58
> To: Oredope, Adetola
> Cc: sip...@li...
> Subject: Re: [Sipdht-devel] SIPDHT Experiments
> 
> Oredope, Adetola wrote:
> > I am actually trying to run some experiments to measure the amount of
> > packets that are exchanged during churn using sipdht.
> > 
> > I am having problems achieving this using the simulator; because I
> don't
> > think I can kill and add peers at the same time. The simulator
> actually
> > breaks when trying to do this. What am I doing wrong?
> 
> Probably nothing, the code is still full of bugs, plus the simulator
> tends to hang when running many nodes because of too many refresh
> operations happening in the GUI.
> 
> > Also as an alternative, I am thinking of using real sipdht peers, i.e.
> > running like 10 instances of a sipdht peers on a single node and then
> > maybe across 10 to 20 nodes.
> 
> That may be a viable option.  I'd suggest to use csipdht2 which is the
> lightest tool in the suite.  If you are interested in churn handling
> only, I'd also suggest to try and disable outbound and gruu (don't
> remember the command line option), which haven't been tested
> extensively.
> 
> > What do you think about this? Also if I follow this approach is there
> a
> > way a seeing an overall map of the overlay? Is there a way of getting
> > exact overall measurements of time, packets exchanged and active
> sessions?
> 
> No, running the peers as standalone processes there's no way to have an
> overall picture of the CAN geometry.
> 
> > I also thinking doing this with the next weeks, do you think this is a
> > feasible time or do I need leave out more time.
> 
> I really cannot answer this question.  What I just can say is that in
> such a distributed and stressed scenario you'll certainly find many
> bugs.  We'll help to fix them, but I really can say anything about
> timings.
> 
> > I look forward from hearing from you all and all suggestions will be
> > highly appreciated.
> 
> I'm sorry for answering this late: it's been a busy busy week.
>