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.