[bind10-dev] Thinking aloud: Multi-CPU auth

[João Damas]

On 20 Dec 2010, at 15:17, Shane Kerr wrote:
> 
>> Another one is using processes and there I see more possible ways:
>> 
>> First, assume we already have the socket creator. The creator (or boss) could
>> cache opened sockets, so it would be possible to provide them to multiple
>> processes. Then, boss could just start multiple auth processes and be happy.
> 
> This is the model I was assuming.

Don't forget to model the data storage properly. You are going to have shared DBs even if you have multiple processes (or things could get really interesting if every process needs a copy of the data). Multiple processes don't automatically solve all contention problems.
Also, do pay attention to how OSs handle Sockets, as the receptionist may create a bottleneck if not implemented properly (possible with  OS specific code)

> 
>> Second, assume we have a receptionist (I still think it might be useful to have
>> it, see next email). Then boss could start multiple auth processes, each one
>> would bind a different port (any random one provided by OS would be fine) and
>> reported itself to the receptionist. The receptionist could guess and balance
>> the load between them.
> 
> This is actually not a horrible idea if we do end up with a
> receptionist. It actually might lead to a nice evolution for
> cluster-based systems, if we move to having a single receptionist for an
> entire cluster of machines. :)
> 

This could be better done with a classical producer-consumer model, where the consumers get to pick the next task from a common pool, rather than implementing complicated code that tries to guess the load on the producer side.

>> Third, assume the OS has fork (I heard there are systems that lack that
>> powerful tool, though). Auth could start, load all the configuration, data (in
>> case of in-memory data source), bind the sockets and then fork as many times as
>> needed (leaving the parent do nothing). In case the configuration changed, the
>> parent would reload it, kill all the children and fork them again (could do it
>> one by one, so we don't go completely dead). The advantage I see here is both
>> the simplicity and the fact that the in-memory data are there only once, shared
>> between the processes.
> 
> The disadvantage here is that the auth server itself has to do process
> management, which I had hoped to avoid. If there is real benefit in it I
> suppose it is a way forward, but... 

what Shane said. Simple is good, over-simplistic is not.

Joao