			*Últimos Cambios*

Mi estado actual en Jabber/XMPP: - jabberES - jabber.org

Cambio de "nick" por petición de un Service

Última Actualización: 14 de Agosto de 2.001 - Martes

A partir de la versión 2.10.H.01 del servidor de IRC-Hispano/ESNET, los services pueden solicitar que un usuario cambie de nick, para evitar así el expulsar de la red a un usuario que esté utilizando un nick registrado y protegido.

Desde el primer momento, esta funcionalidad se ha implementado para un uso exclusivamente temporal, mientras se despliega de forma masiva el sistema de base de datos distribuida para proteger los nicks registrados. En el momento en que se produzca esto, esta funcionalidad quedará obsoleta, ya que nadie se puede poner un nick registrado, si no tiene la clave de acceso para el mismo.

Esta funcionalidad fue solicitada debido a que el 10% de los accesos diarios a la red IRC-Hispano son expulsados por usar un nick registrado sin haberse autentificado.

Para cumplir esta funcionalidad se ha ampliado el protocolo IRC con un comando nuevo:

<Fuente> RENAME <Nick>

Fuente: El nodo que está solicitando el cambio de nick. El cambio debe ser solicitado por un nodo, no por un "nick", y el nodo en cuestión debe tener línea U en la red.
Nick: El nick que solicitamos que cambie de nick. Se trata del nombre ASCII, no de su "numeric".

Con esta funcionalidad, los nicks comprendidos entre "inv000000" y "inv999999" no se admiten como "nick" de usuario, a menos que el nick en cuestión lo esté propagando otro nodo o bien el nodo actual lo esté adoptando siguiendo una petición "RENAME".

El proceso que sigue un nodo cuando recibe un comando "RENAME" es el siguiente:

Si la petición proviene de un "nick", no de un nodo, la ignora.
Si la petición proviene de un nodo que no tiene ULINE, o cuyo enlace de entrada no es correcto para el "spanning tree" actual (un nodo nos intenta inyectar una petición siguiendo una ruta trucada), se genera un "HACK(4)", y el "RENAME" no se sigue propagando.
Si todo va bien, propagamos el "RENAME" al resto de servidores, y enviamos una notificación a aquellos usuarios locales con la máscara "s" correcta.
Si el nick contiene caracteres raros, no nos consta que esté presente en la red o no se trata de un usuario local, nos detenemos aquí.
Si es un usuario local, generamos un nick nuevo e informamos de ello a los usuarios locales con la máscara "s" correcta.
El nuevo nick será "invxxxxxx", donde "x" representa un número de 6 dígitos que es único para cada nick, ya que es su "numeric". En este sentido, no es posible que existan colisiones debido al uso del "RENAME".
Tras la migración a numerics largos, ya no es posible garantizar la unicidad del rename. Ahora se genera un nick al azar hasta que no coincida con ninguno presente en la red. Ello puede provocar kill si hay lag en la red, o si se produce un "net join".
Mientras no se despliegue la nueva versión del servidor por la red, y se dejen de admitir nicks del tipo "invxxxxxx", que con la nueva versión pasan a ser nicks reservados por el sistema, existe la posibilidad de que el nuevo nick elegido para el usuario coincida con el nick de otro usuario de la red, tal vez en otro nodo. Si es el caso, se emite un "KILL" para el usuario que utiliza el nick reservado.
El caso de que se emita un "RENAME" sobre un usuario al que ya se le haya hecho un "RENAME" se contempla adecuadamente, aunque no debería darse nunca.
Si el nick antiguo del usuario tenía modos especiales, como el "r" o el "h", etc., se propaga la desaparición de dichos modos ANTES de propagar el cambio de nick.
Finalmente, se propaga el nuevo nick por la red.

Historia

14/Ago/01: Tras la migración a numerics largos, ya no es posible garantizar la unicidad del rename. Ahora se genera un nick al azar hasta que no coincida con ninguno presente en la red. Ello puede provocar kill si hay lag en la red, o si se produce un "net join".
16/Oct/00: Aclarados algunos puntos sobre el procedimiento que se sigue al recibir un "rename".
15/Oct/00: Primera versión de este documento.