IRC - Internet Relay Chat - (Pag.: 50 - 65)

**Dark[Byte]** Miér Mayo 26, 2010 3:00 am

FC 1459 Protocolo de Charla Basada en Internet Mayo 1993

RPL_BANLIST y RPL_ENDOFBANLIST. Se envía un
RPL_BANLIST por separado para cada identificación de
ban activo. Después de listarse todos (o si no hay
ninguno), debe enviarse un RPL_ENDOFBANLIST.

371 RPL_INFO
":<cadena>"
374 RPL_ENDOFINFO
":Fin de lista /INFO"

- Un servidor que responda a un mensaje INFO debe
enviar toda su información en una serie de mensajes
RPL_INFO con un RPL_ENDOFINFO para indicar el final
de la respuesta.

375 RPL_MOTDSTART
":- <servidor> Mensaje del día - "
372 RPL_MOTD
":- <texto>"
376 RPL_ENDOFMOTD
":Fin del comando /MOTD"

- Cuando se responde al mensaje MOTD y el archivo MOTD
se encuentra, se muestra línea a línea, no superando
cada una los 80 caracteres, usando el formato de
repuesta de RPL_MOTD. Estos deberían abrirse y
cerrarse con un RPL_MOTDSTART (antes de los RPL_MOTD)
y un RPL_ENDOFMOTD (después).

381 RPL_YOUREOPER
":Es usted ahora Operador de IRC"

- RPL_YOUREOPER se envía a un cliente que acaba de
ejecutar con éxito un comando OPER y obtenido estatus
de Operador de IRC.

382 RPL_REHASHING
"<archivo de configuración> :Reconfigurando"

- Si se usa la opción de REHASH y un Operador envía un
mensaje de REHASH, se devuelve un RPL_REHASHING al
Operador.

391 RPL_TIME
"<servidor> :<cadena con la hora local del servidor>"

- Al responder al comando TIME, el servidor debe enviar
la respuesta usando el formato de RPL_TIME de arriba.
La cadena sólo debe contener el día y la hora
correctos. No hay más requerimientos para la cadena.

Oikarinen & Reed [Pág. 51]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

392 RPL_USERSSTART
":UserID Terminal Host"
393 RPL_USERS
":%-8s %-9s %-8s"
394 RPL_ENDOFUSERS
":Fin de usuarios"
395 RPL_NOUSERS
":Nadie conectado"

- Si un servidor recibe un comando USERS, se usan las
respuestas RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS y
RPL_NOUSERS. RPL_USERSSTART debe enviarse primero,
seguido de una sequencia de RPL_USERS o bien de un
sólo RPL_NOUSER. Tras esto se envía RPL_ENDOFUSERS.

200 RPL_TRACELINK
"Enlace <versión & nivel de depuración> \
<destino> <siguiente servidor>"
201 RPL_TRACECONNECTING
"Intentando <clase> <servidor>"
202 RPL_TRACEHANDSHAKE
"H.S. <clase> <servidor>"
203 RPL_TRACEUNKNOWN
"???? <clase> [<dirección IP del cliente en \
forma de números separados por puntos>]"
204 RPL_TRACEOPERATOR
"Operador <clase> <nick>"
205 RPL_TRACEUSER
"Usuario <clase> <nick>"
206 RPL_TRACESERVER
"Servidor <clase> <int>S <int>C <servidor> \
<nick!usuario|*!*>@<host|servidor>"
208 RPL_TRACENEWTYPE
"<nuevo tipo> 0 <nombre de cliente>"
261 RPL_TRACELOG
"Archivo <archivo de registro> <nivel de \
depuración>"

- Los RPL_TRACE* los devuelve el servidor en respuesta
a un comando TRACE. Cuántos se devuelvan depende en
el mensaje TRACE y si lo envió un Operador o no. No
hay un orden predefinido de respuesta. Las respuestas
RPL_TRACEUNKNOWN, RPL_TRACECONNECTING y
RPL_TRACEHANDSHAKE se usan para conexiones que no se
han acabado de establecer y, o son desconocidas o
todavía está intentando conectar o completando el
"choque de manos" del servidor. RPL_TRACELINK lo
envía un servidor que recibe un mensaje de TRACE y
que tiene que pasarlo a otro. La lista de
RPL_TRACELINKs enviados en respuesta a un comando

Oikarinen & Reed [Pág. 52]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

TRACE que atraviesa la red de IRC debería reflejar la
conectividad real de los servidores a través de la
ruta. RPL_TRACENEWTYPE se usará para una conexión que
no entra en las otras categorías pero se muestra
igualmente.

211 RPL_STATSLINKINFO
"<nombre de enlace> <cola de envío [senq]> \
<mensajes enviados> <bytes enviados> \
<mensajes recibidos> <bytes recibidos> \
<tiempo de conexión>"
212 RPL_STATSCOMMANDS
"<comando> <contador>"
213 RPL_STATSCLINE
"C <host> * <nombre> <puerto> <clase>"
214 RPL_STATSNLINE
"N <host> * <nombre> <puerto> <clase>"
215 RPL_STATSILINE
"I <host> * <host> <puerto> <clase>"
216 RPL_STATSKLINE
"K <host> * <nombre de usuario> <puerto> <clase>"
218 RPL_STATSYLINE
"Y <clase> <frecuencia de ping> <frecuencia de \
conexión> <máximo sendq>"
219 RPL_ENDOFSTATS
"<información de estado> :Fin de informe de \
/STATS"
241 RPL_STATSLLINE
"L <máscara de host> * <nombre de servidor> \
<profundidad máxima>"
242 RPL_STATSUPTIME
":Servidor Activo %d días %d:%02d:%02d"
243 RPL_STATSOLINE
"O <máscara de host> * <nombre>"
244 RPL_STATSHLINE
"H <máscara de host> * <nombre de servidor>"

221 RPL_UMODEIS
"<cadena de modo de usuario>"
- Se envía para consultar el modo de un usuario

251 RPL_LUSERCLIENT
":Hay <entero1> usuarios y <entero2> invisibles
en <entero3> servidores

252 RPL_LUSEROP
"<entero> :Operador(es) conectado(s)"

253 RPL_LUSERUNKNOWN
"<entero> :conexion(es) desconocida(s)"

Oikarinen & Reed [Pág. 53]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

254 RPL_LUSERCHANNELS
"<entero> :canal(es) creado(s)"

255 RPL_LUSERME
":Tengo <entero1> clientes y <entero2> \
servidores"

- Al procesar un mensaje LUSERS, el servidor
envía un conjunto de respuestas de
RPL_LUSERCLIENT, RPL_LUSEROP,
RPL_USERUNKNOWN, RPL_LUSERCHANNELS y
RPL_LUSERME. Al responder, el servidor debe
enviar RPL_LUSERCLIENT and RPL_LUSERME. Las
otras respuestas sólo se envían si hay un
contador no a cero para ellas.

256 RPL_ADMINME
"<servidor> :Información de administrador"
257 RPL_ADMINLOC1
":<información de administrador>"
258 RPL_ADMINLOC2
":<información de administrador>"
259 RPL_ADMINEMAIL
":<información de administrador>"

- Al responder a un mensaje ADMIN, un servidor
tiene que usar las respuestas RLP_ADMINME a
RPL_ADMINEMAIL y proporcionar un mensaje de
texto con cada una. Para RPL_ADMINLOC1 se
espera una descripción de la ciudad, estado y
país, seguido por los detalles de la
universidad y departamento (RPL_ADMINLOC2), y
finalmente, el contacto de administrador del
servidor (se requiere una dirección de correo
electrónico) en RPL_ADMINEMAIL.

Oikarinen & Reed [Pág. 54]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

6.3 Respuestas reservadas

Estas respuestas no se describen arriba ya que caen en una de las
siguientes categorías:

1. ya no se usan;

2. están reservadas para usos futuros;;

3. están en uso pero son parte de características no genéricas
del servidor.

209 RPL_TRACECLASS 217 RPL_STATSQLINE
231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES
233 RPL_SERVICE 234 RPL_SERVLIST
235 RPL_SERVLISTEND
316 RPL_WHOISCHANOP 361 RPL_KILLDONE
362 RPL_CLOSING 363 RPL_CLOSEEND
373 RPL_INFOSTART 384 RPL_MYPORTIS
466 ERR_YOUWILLBEBANNED 476 ERR_BADCHANMASK
492 ERR_NOSERVICEHOST

7. AUTENTICACION DE CLIENTE Y SERVIDOR

Los clientes y los servidores están sujetos ambos al mismo nivel de
atenticación. Para ambos, se realiza una búsqueda de número IP y
nombre de host (y la comprobación inversa de éste) para cada
conexión hecha al servidor. Ambas conexiones están sujetas después a
una comprobación de clave (si hay una clave establecida para esa
conexión). Estas comprobaciones son posibles en todas las conexiones
aunque la comprobación de clave sólo se usa habitualmente con
servidores.

Una comprobación que se está haciendo más común es la del usuario
responsable de la conexión. Encontrar el usuario del otro lado de la
conexión normalmente requiere la conexión a un servidor de
autenticación como IDENT, descrito en el RFC 1413.

Dado que sin claves no es fácil de determinar fiablemente quién está
al otro lado de una conexión de red, se recomienda encarecidamente
el uso de claves en conexiones entre servidores además de otras
medidas como el uso de un servidor de ident.

8. DETALLES DE IMPLEMENTACIÓN

La única implementación actual de este protocolo es el servidor de
IRC, versión 2.8. Versiones posteriores pueden implementar algunos o
todos los comandos descritos por este documento con mensajes de
NOTICE sustituyendo muchas de las respuestas numéricas. Por

Oikarinen & Reed [Pág. 55]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

desgracia, debido a los requerimientos de compatibilidad inversa, la
implementación de algunas partes de este documento varía con lo que
se expresa. Una diferencia importante es:

* reconocer cualquier carácter LF (Line Feed - Fin de Línea) o
CR (Carriage Return - Retorno de Carro) en cualquier parte de
un mensaje como el fin de dicho mensaje (en lugar de requerir
CR-LF)

El resto de esta sección trata de los puntos de mayor importancia
para aquellos que deseen implementar un servidor, pero la mayoría de
las partes se aplican también directamente a los clientes.

8.1 Protocolo de red: TCP - porqué es adecuado usarlo aquí

El IRC se ha implementado sobre TCP ya que TCP proporciona un
protocolo de red fiable que encaja bien con este tipo de
"conferenciación". El uso de [multicast] IP es una alternativa, pero
no está demasiado disponible o soportada en la actualidad.

8.1.1 Soporte de sockets UNIX

Dado que los sockets de dominio de UNIX permiten operaciones de
escucha/conexión, la implementación actual puede configurarse para
escuchar y aceptar conexiones tanto de cliente como servidor en un
socket de dominio UNIX. Estos se reconocen como sockets donde el
nombre de host comienza con un '/'.

Al proporcionar información sobre las conexiones en un socket de
dominio UNIX, el servidor debe colocar el nombre de host real en el
siito del camino (path) a no ser que se pregunte por el nombre del
socket.

8.2 Análisis de comandos

Para proveer una Entrada/Salida de red útil y sin buffer para los
clientes y servidores, cada conexión obtiene su buffer de entrada
propio y privado en el cual se guardan los resultados de las
lecturas y análisis más recientes. Un tamaño de buffer de 512 bytes
se usa para guardar un mensaje completo, sin embargo, normalmente
podrá alojar varios comandos. El buffer privado se analiza después
de cada operación de lectura de mensajes válidos. Al tratar con
múltiples mensajes de un cliente en el buffer, debe tenerse cuidado
en caso de que uno resulte en la eliminación del cliente.

8.3 Envío de mensajes

Es común encontrar enlaces de red saturados o hosts a los que usted
envía datos pero que es incapaz de enviar datos. Aunque UNIX
normalmente maneja esto a través de la ventana TCP y búffers
internos, el servidor tiene a menudo grandes cantidades de datos

Oikarinen & Reed [Pág. 56]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

para enviar (especialmente cuando se forma un nuevo enlace servidor-
servidor) y los pequeños búffers del núcleo no son suficientes para
la cola de salida. Para aliviar este problema, se usa una "cola de
envío" como cola FIFO para los datos a enviar. Una "cola de envío"
típica puede ser de hasta 200 Kilobytes en una red IRC grande con
conexiones lentas en la conexión de un nuevo servidor.

Al elegir sus conexiones, un servidor debe leer y analizar primero
todos los datos de entrada, encolando los datos a enviar. Cuando se
procesen todas las entradas disponibles, se envían los datos de la
cola. Esto reduce el número de llamadas de sistema a write() y ayuda
a TCP a hacer paquetes más grandes.

8.4 Vida de una conexión

Para detectar cuando una conexión ha muerto o no responde, el
servidor debe comprobar cada una de sus conexiones (mandar ping) de
las que no tenga respuestas en un intervalo de tiempo dado.

Si una conexión no responde a tiempo, su conexión se cierra usando
los procedimientos adecuados. La conexión también se cierra si su
cola de envío crece por encima del máximo permitido, porque es mejor
cerrar una conexión lenta que tener el proceso de un servidor
bloqueado.

8.5 Estableciendo una conexión cliente-servidor

Tras conectarse a un servidor IRC, se envía al cliente el MOTF (si
se encuentra), además del contador actual de usuarios/servidores
(como se presenta por el comando LUSER). El servidor debe además dar
un mensaje no ambiguo al cliente que indique su nombre y versión,
así como cualquier otro mensaje introductorio que pueda considerarse
apropiado.

Tras esto, el servidor debe enviar el nick del nuevo usuario y otra
información proporcionada por él mismo (comando USER) y que el
servidor pueda descubrir (de servidores DNS/autenticación). El
servidor debe enviar esta información con NICK primero, seguido de
USER.

8.6 Estableciendo una conexión servidor-servidor

El proceso del establecimiento de una conexión servidor-servidor no
está exenta de riesgo ya que hay muchas partes en las que puede
haber problemas - los menores son condiciones de carrera.

Después de que un servidor reciba una conexión seguida de un par
PASS/SERVER que se han reconocido como válidos, el servidor debería
responder con su propia información PASS/SERVER para esa conexión al
igual que toda la información de estado que conozca de la forma
descrita a continuación.

Cuando el servidor que inicia la conexión recibe un par PASS/SERVER,

Oikarinen & Reed [Pág. 57]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

chequea que el servidor que responde se ha autenticado correctamente
antes de acecptar que la conexión sea de ese servidor.

8.6.1 Intercambio de información de estado al conectar

El orden de la información de estado que se intercambia entre los
servidores es fundamental. El orden requerido es el siguiente:

* todos los otros servidores conocidos;

* toda la información sobre los usuarios conocidos;

* toda la información de los canales conocidos.

La información referente a los servidores se envía por mensajes
SERVER extra, la información de usuarios con mensajes NICK/USER/
MODE/JOIN y los canales con mensajes MODE.

NOTA: los tópicos de canal *NO* se intercambian aquí ya que el
comando TOPIC sobreescribe cualquier información anterior del mismo.

Al pasar primero la información de estado sobre los servidores,
cualquier colisión con servidores que ya existen ocurren antes de
las colisiones de nick debidas a un segundo servidor que introduce
un nick en particular. Debido a que la red de IRC sólo existe como
grafo acíclico, es posible que la red ya se haya reconectado en otra
posición, el lugar de la colisión indicando dónde debe separarse la
red.

8.7 Finalización de conexiones cliente-servidor

Cuando se cierra una conexión de cliente, el servidor al cual el
cliente conectó genera un mensaje de QUIT en representación del
cliente. No se genera o usa otro mensaje.

8.8 Finalización de conexiones servidor-servidor

Si se cierra una conexión servidor-servidor, bien via un SQUIT
remoto o por causas "naturales", el resto de la red IRC debe
actualizar su información del servidor que detectó el cierre de la
conexión. El servidor envía una lista de SQUITs (una por cada
servidor tras esa conexión cerrada) y una lista de QUITs (de nuevo,
una por cada cliente tras esa conexión).

Oikarinen & Reed [Pág. 58]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

8.9 Seguimiento de cambios de nick

Todos los servidores IRC deben mantener un registro histórico de los
cambios de nick recientes. Esto es obligatorio para permitir que el
servidor tenga la ocasión de seguir la pista de los cambios cuando se
dan condiciones de carrera en cambios de nick, debidas a las órdenes
que los manipulan. Los comandos que deben seguir los cambios de nick
son:

* KILL (el nick que se expulsa del IRC)

* MODE (+/- o,v)

* KICK (el nick que se expulsa del canal)

Ningún otro comando tiene que comprobar cambios de nick.

En los casos anteriores, el servidor debe comprobar primero la
existencia del nick, después chequear su historial para ver a quién
pertenece ese nick en la actualidad (si existe). Esto reduce las
posibilidades de carrera pero aún pueden ocurrir y acabar en que el
servidor actúe sobre el nick equivocado. Al hacer un seguimiento de
cambio para un comando de los anteriores se recomienda dar un
intervalo de tiempo y las entradas que sean muy antiguas ignorarlas.

Para un historial razonable, un servidor debería ser capaz de
mantener nicks anteriores para cada cliente que conoce si todos
decidieron cambiarlo. El tamaño viene limitado por otros factores
(tales como memoria, etc).

8.10 Control de flood de clientes

En una red grande de servidores de IRC, es fácil que un solo cliente
conectado a la red proporcione un flujo continuo de mensajes que
resulten no sólo en una "inundación" de la red, sino también en la
degradación del servicio a los demás. Más que requerir la protección
de cada "víctima", la protección contra flood se incluyó en el
servidor y se aplica a todos los clientes salvo a los servicios. El
algoritmo actual es el siguiente:

* comprobar si el "contador de mensaje" del cliente es menor
que la hora actual (se pone igual si lo es);

* leer datos del cliente;

* mientras el contador sea menor de diez segundos por delante
de la hora actual, analizar cualquier mensaje y penalizar al
cliente con 2 segundos por mensaje;

Oikarinen & Reed [Pág. 59]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

lo que, en esencia, significa que el cliente puede enviar 1 mensaje
cada 2 segundos si verse afectado.

8.11 Búsquedas sin bloqueos

En un entorno de tiempo real, es esencial que el proceso de un
servidor espere lo menos posible de forma que se sirva a todos los
clientes de forma justa. Obviamente esto requiere que no haya
bloqueos de Entrada/Salida en las operaciones de lectura/escritura.
Para conexiones de servidores normales, esto no es difícil, pero hay
otras operaciones que pueden ocasionar un bloqueo del servidor (como
lecturas de disco). Cuando sea posible, estas actividades deberían
realizarse con una pausa corta.

8.11.1 Resolución de nombre de host (DNS)

El uso de las librerías de resolución de Berkeley y otras ha
significado importantes retardos en algunos casos en que las
respuestas han expirado. Para evitar esto, se escribió un conjunto
aparte de rutinas DNS, las cuales fueron diseñadas para operaciones
de E/S sin bloqueo y sacadas fuera del bucle principal de E/S del
servidor.

8.11.2 Búsqueda de nombre de usuario (Ident)

Aunque hay muchas bibliotecas de ident, ocasionaron problemas ya que
operaban de forma síncrona y resultaba en retrasos frecuentes. La
solución, de nuevo, fue escribir unas rutinas que cooperaban con el
resto del servidor y trabajan usando E/S sin bloqueo.

8.12 Archivo de configuración

Para proporcionar una forma flexible de configurar y ejecutar el
servidor, se recomienda el uso de un archivo de configuración que
contenga instrucciones al servidor referentes a:

* de qué hosts se aceptan conexiones cliente;

* de qué hosts se permiten conexiones de servidor;

* a qué hosts conectarse (activa y pasivamente);

* información sobre la localización del servidor (universidad,
ciudad/estado, compañía ...);

* quién es el responsable del servidor y una dirección de
correo electrónico de contacto;

* nombres de host y claves para los clientes que desean acceso
a los comandos restringidos de Operador.

Oikarinen & Reed [Pág. 60]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

Al especificar nombres de host, tanto nombres de dominio como
notación "de punto" (127.0.0.1) deben aceptarse. Debe ser posible
especificar la clave usada/aceptada para todas las conexiones
entrantes y salientes (aunque las únicas conexiones salientes son a
otros servidores).

La lista anterior son los requerimientos mínimos para un servidor
que quiera conectarse a otro. Otros aspectos de utilidad son:

* especificar a qué servidores puede presentarse otro servidor;

* la profundidad máxima de la rama de un servidor;

* número máximo de horas de conexión de los clientes.

8.12.1 Permitir la conexión de clientes

Un servidor debería usar alguna clase de "lista de control de
acceso" (bien en el archivo de configuración o en otra parte) que se
lea al iniciar y se use para decidir qué hosts pueden usar los
clientes para conectarse.

Tanto "denegar" como "permitir" deberían implementarse para
proporcionar la flexibilidad requerida para el control de acceso de
host.

8.12.2 Operadores

La concesión de privilegios de Operador a una persona inapropiada
puede tener consecuencias directas para la buena marca de la red de
IRC en general debido a los poderes que se otorgan. Por esto, la
obtención de dichos poderes no debería ser fácil. La configuración
actual requiere dos claves aunque una de ellas normalmente es fácil
de averiguar. Es mejor guardar las claves de Operador en archivos de
configuración que incluirlas en el código y deberían guardarse en
formato encriptado (por ejemplo, usando crypt(3) de UNIX) para
evitar el robo fácil.

8.12.3 Permitir la conexión de servidores

La interconexión de servidores no es un problema trivial: una mala
conexión puede tener un gran impacto en la utilidad del IRC. Por
ello, cada servidor debería tener una lista de los servidores a los
que se puede conectar y los que se pueden conectar a él. Bajo
ninguna circunstancia debe un servidor permitir la conexión de un
host cualquiera como servidor. Además de los servidores que pueden y
no pueden conectar, el archivo de configuración debería contener
también la clave y otras características del enlace.

Oikarinen & Reed [Pág. 61]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

8.12.4 Administración

Para proporcionar respuestas válidas y completas al comando ADMIN
(ver sección 4.3.7), el servidor debe incluir los detalles
relevantes en la configuración.

8.13 Miembros de canales

El servidor actual permite a un usuario local registrado ser miembro
de hasta 10 canales diferentes. No hay límite para los usuarios no
locales de forma que el servidor sea (razonablemente) consistente
con todos los demás en base a los miembros de un canal.

9. PROBLEMAS ACTUALES

Hay unos cuantos problemas relacionados con este protocolo, que se
espera que sean solventados en un futuro cercano. Actualmente, se
está trabajando para solucionar estos problemas.

9.1 Escalabilidad

Se sabe perfectamente que este protocolo no escala suficientemente
bien cuando se usa de una forma muy masiva. El problema más
importante viene del requisito de que todos los servidores sepan
sobre los demás y sobre los usuarios, y que la información referente
a ellos se actualice al cambiar. También es deseable mantener un
reducido número de servidores para que la longitud del camino entre
dos puntos sea mínima y que el árbol de expansión esté lo más
ramificado posible.

9.2 Etiquetas

El protocolo actual de IRC tiene tres tipos de etiquetas: nick,
nombre del canal y nombre del servidor. Cada uno de los tipos tiene
su propio dominio y no se permite duplicidad dentro de cada uno.
Actualmente es posible que los usuarios cojan la etiqueta de uno de
los tres, lo que acaba en colisiones. Se sabe que esto necesita más
trabajo, con un plan para nombres únicos para canales y nicks que no
colisionen, y una solución que permita un árbol cíclico.
N. del T.: un árbol por definición es acíclico (grafo sin ciclos),
pero se conserva la traducción literal.

9.2.1 Nicks

La idea de nick en el IRC es muy conveniente de cara a los usuarios
para hablar entre ellos fuera de un canal, pero hay un espacio finito
de nicks y por lo que son, no es raro que varias personas quieran el
mismo. Si dos personas usando este protocolo escojen el mismo nick,
bien uno no lo conseguirá o los dos serán eliminados mediante el uso
de KILL (sección 4.6.1).

Oikarinen & Reed [Pág. 62]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

9.2.2 Canales

La composición de canales actual requiere que todos los servidores
conozcan sobre todos los canales, sus miembros y propiedades. Aparte
de no escalar bien, el asunto de la privacidad es también importante.
Una colisión entre canales se trata como evento inclusivo (los dos
que crearon el nuevo canal se consideran miembros de él) más que
exclusivo como en el caso de las colisiones de nicks.

9.2.3 Servidores

Aunque el número de servidores normalmente es pequeño comparado con
el de usuarios y canales, ambos necesitan ser conocidos globalmente,
ya sea cada uno por separado o enmascarados.

9.3 Algoritmos

En algunas porciones de código del servidor, no se han podido evitar
algoritmos N^2, como el chequeo de la lista de canales de un conjunto
de clientes.

En las versiones actuales del servidor, no hay chequeo de la
consistencia de la base de datos, cada servidor supone que el
servidor vecino es correcto. Esto abre las puertas a problemas
grandes si un servidor conectado está defectuoso o intenta introducir
contradicciones a la red.

En la actualidad, debido a la escasez de etiquetas internas y
globales únicas, hay muchas condiciones de carreras que pueden darse.
Estas normalmente vienen del tiempo que lleva a los mensajes
atravesar la red de IRC. Incluso cambiando a etiquetas únicas, hay
problemas de interrupción de comandos relacionados con los canales.

10. SOPORTE Y DISPONIBILIDAD

Listas de correo para discusiones sobre IRC:
Protocolo futuro: ircd-three-request@eff.org
Discusión general: operlist-request@eff.org

Implementación de software:
cs.bu.edu:/irc
nic.funet.fi:/pub/irc
coombs.anu.edu.au:/pub/irc

Grupos de noticias: alt.irc

11. ASUNTOS DE SEGURIDAD

Estos se discuten en las secciones 4.1, 4.1.1, 4.1.3, 5.5 y 7.

Oikarinen & Reed [Pág. 63]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

12. DIRECCIONES DE LOS AUTORES

Jarkko Oikarinen
Tuirantie 17 as 9
90500 OULU
FINLANDIA

Correo electrónico: jto@tolsun.oulu.fi

Darren Reed
4 Pateman Street
Watsonia, Victoria 3087
Australia

Correo electrónico: avalon@coombs.anu.edu.au

Traductor:
Carlos García Argos
C/Antonio Trueba, 14; 4-8-2
29017 MALAGA
ESPAÑA/SPAIN
Correo electrónico: cgasoft@yahoo.com

Oikarinen & Reed [Pág. 64]