It will be hard to get a list of up and running; the only thing servers
know about up and running servers is the server ID and some TCP/IP
connections via which the server can be reached. It doesn't know
how far away other servers are.
However, as server ID's are static (a server will keep a ID for as long
as it lives), a user could ftp a list of servers from some site, in
which the server's IP hostname, server ID, administrator and other
stuff are. This list is already online at
http://wwcn.student.utwente.nl/wwcn/nag/servers.db
I don't think I mentioned it on this mailinglist, perhaps I told some
ppl in private, but there's another idea that can be well implemented:
a client maintains a list of servers it has an 'account' on. A client
has an account as soon as it has received a password after it has
registered itself. So this list could be a list of {server address,
server port, server id, password} records. The server ID is a key
into the servers.db file so that the client can give administrative
information when the user requests it.
When a server goes down, or is not reachable, the client can take
the next record and try to connect to that server.
A server that is shutting down, and is still healty enough to send
network messages, will send an "IDIE" message to the clients. The
format of this is:
860 Shutting down: %s
with %s being the reason why the server is shutting down. The numeric will
be the same for level 2 and level 3 clients. It will probably not change,
the text may change but will be informative and appropriate. It can be
used by "lazy" clients.
Messages that are sent on channels (and also private messages ??) are
numbered. When a client connects to another server, it will loose some
messages while reconnecting and rejoining the channels it was on.
The idea is that the new server it has connected to, can somehow get
a backlog somewhere so that the client won't have to miss anything.
The problem here is that the new server may not have been on the
channel, and doesn't have a backlog itself. I do not know yet how
a server could get a backlog. Perhaps a special backlog service is
needed. However, the protocol will include messages to request a
backlog, and for the server to either send the backlog or give a
reason why they aren't available. I don't know what implications this
has for the client code, but.. that's up to the coders ;)
NB if a client is not registered at any server, it must use the ID
0 in its "IAM" message. If it is registered, it must use the ID it
received from the first server it registered at. This ID will be
the global user ID of the user, which must be used regardless of
the server it connects to.
well, enough talk for now. Back to work. Piece by piece the client
protocol will become clear..
grit