mixster

micsti: simplified.

Overall server hierarchy (required unless stated optional):

    Central routing servers/s (optional) � they handle connections to direct people to appropriate channels. The only server required to be up at all times, but the low load should make it easy to do.
    Channel owner � handle connections to the channel. It is in charge of handling new clients joining a channel, maintaining even distribution of clients to channel servers (after a channel server goes down and when new clients join). Depending on setup, may also transmit text to and from clients (required if no channel servers), but should focus on server to server discussions primarily.
    Channel server (optional) � handles a proportion of the transmitting of text between joined clients (and any other servers where applicable).
    Clients (optional) � send and receive messages from one or more servers. No server functionality required, but any client implementations should be able to be run as servers.

The central routing server is optional as the client could directly connect to the channel (or cluster) and so being redirected isn�t needed. If no central server does exist, then there is no technical owner as connecting to any of the channel servers should be able to work, however they should instead transparently forward them on to the channel owner.

Channel owners and channel servers are identical, the only difference being some accessible commands that go via the central routing server. In the case of a central routing server existing, the channel owner has a special relationship with it to ensure that it is the owner else the channel owner is simply a channel server. Also, an heir may be implemented where by when the channel owner dies the central routing server promotes the heir channel server to channel owner status.

Channel servers work by connecting to each other and their specified group of clients. By clustering them within a channel, the servers always have very short routes. In terms of how the servers connect to each other, I suggest an each to many system, where by each message received is sent to multiple servers and they spread it as needed, resulting in the client receiving multiple of the same message to ensure validity and lack of tampering.

Clients themselves have no server functionality required. They should send and receive messages to/from multiple servers to ensure validity and lack of tampering. The number of servers the client is connected to should be much smaller than the number of other servers each channel server is connected to, in order to avoid large amounts of the same text, but enough to still give them protection from malicious servers.