|
Distributing the channels across all muds is probably the most preferable thing to do. And it's also a very easy thing to do with a top-down design and a client-server model using the idioms I mentioned.
When I say "client-server", I mean that one instance of the program acts like a client in some cases, and one instance acts like a server in some cases. Some instances will be more like a server than a client in that more people will connect to them (hubs), and some instances will act solely like clients (leafs). But I still think that the program should have support for both -- that a network should not be benevolantly dictated; instead existing as a collection of equals.
Actually, one can still gain a great deal of the benefits of the client-server model with a top-down distributed model. If every server knows its subscriptions and the subscriptions of those immediately connected to it, it can propogate information without having to query each time. All we have to do now is stack the subscriptions, so a leaf hub will tell the main hub all of the subscriptions of its clients. When information for that channel has been received, the hub will simply send to all clients (which are possibly other hubs) that need it. And it's robust in that if a hub is offline, as long as a leaf knows the address of another hub, it can simply reconnect there.
Now make that all automatic -- distribute a list of hubs and have clients ping for latency, and you've got quite a powerful network.
|