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

[David Westley]

Yeah that all makes sense to me, however the serverlink linked list will be re-
ordering itself so many times that I'm worried about CPU time so what if you 
just update an idle time in them and then the one with the highest idle time 
is the one that gets dropped?

David

-----Original Message-----
From: Jan Krueger <address@hidden>
To: address@hidden
Date: Wed, 12 Mar 2003 20:47:24 +0100
Subject: [Unity-irc3] network design - to route or not to route?

> 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
> 
> 
> 
> _______________________________________________
> irc3 (Unity) public discussion mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/unity-irc3