Re: Lag-kills.

[kalt@xxxxxxxxxxx (Christophe Kalt)]

On Feb 1, Vegard Engen wrote:
| - A separate class of nick to stop nick-change-looping. Servers would refuse 
| nicks of this class from client connections, but not from server-connections.

I don't get this

| - Find out how to introduce this gradually, so it won't need an immediate 
| upgrade of servers. This one, I will think hard about right now, but please, 
| if you have ideas, come with them.

It shouldn't be a problem, as of 2.9, server connections
include a version exchange/identification to decide what
protocol is being used (for now 2.8 or 2.9)
2.9.3 goes even further, by negociating link parameters upon
connection.

| - Client change to recognize the forced nick change. This is the hunch, 
| really. But, think of it, if you've been collided, what would be the harm of 
| the client just screwing up instead of you being thrown totally off. But 
| still, I have an idea that might help - the server the client is on, will 
| expect an acknowledgement from the client within some time. If it don't get 
| it, it will drop the client. This way, the screwed user will have to 
| reconnect, and will hopefully soon find out that he needs a new client.

I find it easier to let the client pick the new nick.
*** You have been rejected by server toto.tata
*** Enter a new nickname

That way, servers don't have to randomly generate nicks, and
you cannot predict either, nor can you get into some loop
between servers themselves.

| Please, tell me whether or not this is doable, or if it's rubbish :)

I don't like much the idea of FNC.
Now, if you get collided, you have to reconnect, and rejoin
all channels.
With a working FNC, you keep the connection, the channels,
the channel ops, but you're still annoyed.

Besides, in your scheme, what happens to the messages sent
to the nick? They bounce?  This would be acceptable for
PRIVMSGs, but could create desynchs (notonly mode wise) on
channels.  The way to solve this is having unique IDs used
for the "recipient" part of all messages which requires
major changes to the server code (I tried, but gave up
lacking time).  (IDs should also be used for the source, but
that is easy)

| PS. The gradual introduction-scheme is coming. It might not be much of a 
| problem, I just need to sort the thoughts out.

I find a convenient solution is to flag users.
So when a collision occurs, you know if you can force the
change on the user or not.