head 1.5; access; symbols; locks; strict; comment @# @; 1.5 date 2000.05.03.16.13.03; author kalt; state Exp; branches; next 1.4; 1.4 date 97.09.29.12.05.57; author kalt; state Exp; branches; next 1.3; 1.3 date 97.06.12.13.01.21; author kalt; state Exp; branches; next 1.2; 1.2 date 97.04.14.20.17.05; author kalt; state Exp; branches; next 1.1; 1.1 date 97.04.14.20.12.09; author kalt; state Exp; branches; next ; desc @&KILLS explanation @ 1.5 log @moved to irc.org, fixed links @ text @
This document assumes that you already have knowledge of the IRC protocol and that you understand it.
Field short description:
Example: ircd.stealth.net!*.fi[unknown@@ircd.funet.fi]!*.hu[unknown@@irc.bme.hu]!irc.bme.hu
In this example, we can follow the path took by the KILL to reach us:
This is commonly known as a Fake Prefix error condition. nickname has been introduced by server1 but server2 is sending data claiming it comes from nickname (which is impossible since nickname is behind server1 and not behind server2).
Both server1 and server2 are local connections.
server2 is a new server being introduced on the network, but its name is currently being used by another client as a nickname (this client was introduced by server1). This is a Server/nick collision.
The nickname being killed is being introduced by server2 and is supposed to be a client using server1. It is impossible because server1 is not behind server2.
server is propagating an illegal nickname change for nickname!user@@hostname.
This is a Nick/Server collision, the local connection is a server which introduced a nickname using the same name as a server behind server1.
This is a ``classic'' nickname collision. The nickname being killed was known from server1 but server2 introduced it again. user2@@host2 identifies the new user which was being introduced, and user1@@host1 the user which got collided.
This is a ``nickname change'' collision. Both nick1 and nick2 are registered clients. The server issuing the kill does so because nick2 tried to change its name to nick1 (which is already taken).
In theory this shouldn't happen. However, large networks are commonly affected by ``lag'' (delays) which makes this kind of situation possible.
Christophe Kalt <kalt@@stealth.net>
$Id: kills.html,v 1.4 1997/09/29 12:05:57 kalt Exp kalt $@ 1.4 log @ajout du paragraphe "nickname change collision". @ text @d1 4 a4 2
$Id: kills.html,v 1.3 1997/06/12 13:01:21 kalt Exp kalt $d125 1 a125 1 @ 1.3 log @fixed typo (from Alain Nissen
d74 1 a74 1
d80 1 a80 1
d86 1 a86 1
d91 1 a91 1
d96 1 a96 1
d98 2 a99 2 This is a ``classic'' nickname collision. The nickname being killed was known from server1 but d103 11 a113 4
The new user introduced can either be a new client on the network, or an old one trying to change nickname at the wrong time. d121 1 a121 1
$Id: kills.html,v 1.2 1997/04/14 20:17:05 kalt Exp kalt $@ 1.2 log @added $Id$ @ text @d101 1 a101 1
d118 1 a118 1
$Id$d120 1 a120 1