[Unity-irc3] network design - to route or not to route?

[Jan Krueger]

Hi everyone,

I've already mentioned in another post that I want quite another network code
than the classic ircd one. Most importantly, I want to get rid of the concept
of hubs and leafs. My suggestion is to do all connections in a flat
organisation, like this:
We allocate a maximum number of FDs for server-server connections (config
option or so). Let's call that bunch of FDs the serverconn pool.
Then, when we need to connect to a server, we take one of those
FDs and put it into a linked list of used FDs (let's call this list the
servlink list), at the very start of the list.
When there is activity on a link, the FD is again moved to the start of the
list if it's not already there. We might want to exclude PING messages from
this since we don't want all FDs to keep being moved around on the list even
if there's no _real_ activity on them.
As long as there are still unused FDs in the serverconn pool,
everything's fine and we don't need to worry about anything. If, however, all
FDs are used, we have them all in the servlink list, most recently used links
first. Since the last entry in the list has got to be the most idle one, it
would make sense to close that connection and use the FD to create a
connection to the new server, putting the FD at the top of the list again.
By doing this, only the most used FDs should be connected quite permanently.

Let's have a look at the alternatives:
1) stick with the old hub/leaf concept. - This is not only redundant since
messages will already hop over several internet routers even if we have a flat
connection, so if we add our own hub code, that can't really optimize a lot in
terms of traffic or speed. Also, if the networks get bigger, central hubs will
get a really heavy load.
2) uh, good question. Can you think of another solution? Don't say multicast
now or I'll have to shoot you.

Does this make sense?

-- 
regards,
Jan Krüger
http://www.jast-dev.net.tc