[IRC-DEV] Funcionamiento del comando WATCH

[RoMaNSoFt]

On Mon, 20 May 2002 18:11:05 +0200, you wrote:

>Cada vez que conectes al IRC, has de enviar los nicks al servidor (los
>clientes, sobre todo el mIRC lo hacen automáticamente) ya que al salir de la
>red se borra toda la lista.

 Y me pregunto yo: ¿no sería factible / interesante que esta lista de
nicks iniciales los guardará el servidor en bbdd? =)

 La principal ventaja es obvia: tu lista de "'watches" no dependerá,
como viene siendo habitual en notifies o en la implementación actual
de watch, de que te conectes desde TU ordenador + TU cliente habitual.
Es decir, si te conectas desde distintos sitios (desde el curro, casa,
casa de un amigo, cyber, distintos clientes IRC aunque sea en tu
propio ordenador, étc) esto aseguraría q en todos los casos obtienes
la misma lista de Watches, es decir, aseguras la coherencia de la
lista, con independencia del lugar donde te conectes. Desde mi punto
de vista, esta funcionalidad sería MUY útil. De hecho los clientes más
habituales de mensajería como son el ICQ o el Messenger incorporan
esta "feature" desde hace tiempo y es MUY útil. Otro ejemplo más:
cuando reinstalas el mIRC, o todo el SO, el HD casca, ... perderías tu
lista de watches (los puristas me preguntaran si no se lo q es un
backup... bien, a mi no me lo pregunteis; hacedlo a TODOS los usuarios
"llanos" de la red IRC, q apenas saben lo q es un ordenador).

 Otra ventaja (secundaria pero adicional) podría ser que quizás
agilizase un poquito la conexión de los usuarios al IRC. Me explico.
Tradicionalmente, uno de los pasos en el setup de sesión de IRC (por
llamarlo de alguna forma) es el handshaking de notify's: el cliente
envía la lista completa de nicks y el server responde con los nicks (y
los datos correspondientes) que están online. En realidad, y esto me
lo tendréis q puntualizar ya que no lo recuerdo, probablemente el
servidor envié un mensaje negativo, si el nick en cuestión no está
online. Si un usuario mantiene una lista de notify's bastante grande
(y muchos así lo hacemos) se produce un lag al conectar, ya que por
cada nick q tenemos en la lista se produce una petición y
(probablemente) una respuesta. Pues bien, si la lista de watch'es
estuviera en bbdd el tráfico cliente<->servidor se reduce, ya que
ahora todo se reduce a mensajes "de respuesta" (sin ninguna petición)
y además sólo uno por nick online.

 Por ejemplo, el caso más óptimo es un usuario con una lista de
"watches" de 20 nicks (p.ej.), y que resulte q ninguno de ellos está
online. El resultado es que no habría tráfico de mensajes alguno
(_entre cliente y servidor_). Nos hemos ahorrado "subir" la lista de
watch'es al servidor desde el cliente, lo cual es un ahorro de tiempo
apreciable.

 La única desventaja que le veo a todo esto es el posible coste de
implementación, que en mi opinión no es demasiado elevado (al menos en
comparación con las grandes ventajas que se obtienen para el usuario).

 Analicemos esto último:
- un nick tiene long. 9 chars (lo q en mi opinión, y a estas alturas,
es un poco escaso; pero bueno, este es otro tema que ya ha sido
tratado y como a Jcea le sobran todavía 5 de esos 9 caracteres...
:-PPP)
- supongamos que se permite una lista de watch'es "iniciales" de 20
nicks por usuario registrado.
- supongamos un elevado núm. de usuarios registrados: 150.000 (no está
mal, ¿no? :-P)

 Si hacemos cuentas en el (pésimo) caso de que todos los usuarios
hayan "gastado" por completo su lista de watch'es, tendríamos q:

 9 x 20 x 150000 = 27000000 bytes = ~ 25.75 MBytes

 Luego el coste en almacenamiento en bbdd es de aprox. 26 MB, lo q en
estos tiempos no supone gran cosa (y recordemos q estamos en el caso
más desfavorable).

 En cuanto a rendimiento, cargar una lista de (máx) 20 nicks por cada
user que se conecta a la red (y se autentifica por nick2, p.ej.),
tampoco es grande (no se van a autentificar 150.000 users _en el
mismo_ instante y _ante el mismo_ servidor).

 Respecto a la actualización de la lista inicial de watches, hay 2
opciones:
a) Cada "watch +/- nick / c" suponga la actualización automática de la
lista "inicial" de watch'es, lo cual puede suponer un pequeño impacto
en cuanto a rendimiento.
b) Se implemente una nueva opción para el comando watch, por ejemplo,
un "watch save" q conlleve la actualización de los nicks iniciales de
la lista de watch correspondiente al user q lo ejecute. En este caso
el impacto en cuanto a rendimiento es mucho menor y totalmente
controlable (por ejemplo, se puede poner un umbral de forma q un mismo
user no pueda realizar 2 save's consecutivos en un espacio de tiempo
X, con lo cual evitaríamos un posible flood de "saves").

 Sup q aquí habría q hacer pruebas de rendimiento. La opción a) es más
cómoda de cara al usuario y tampoco creo q influya mucho
(negativamente) en el rendimiento, aunque es evidente q lo hará en
mayor grado q la b).

 ¿Cómo lo veis?

 Salu2,
 --Roman