23.1. Algunos aspectos internos de INN

El n�cleo de INN es el demonio innd. La tarea de innd es manejar todos los art�culos entrantes, los almacena y se los pasa a cualquier proveedor de noticias que los requiera. innd se activa cuando se carga el n�cleo del sistema y queda trabajando de forma continua en segundo plano. Corriendo como demonio se incrementa el rendimiento ya que solamente cuando se inicia se leer�n los archivos de estado. Dependiendo del volumen del proveedor de noticias, algunos archivos como por ejemplo history (que contiene una lista de todos los art�culos procesados recientemente) puede estar en el rango que va desde unos pocos megabytes hasta varias decenas.

Otra caracter�stica importante de INN es que solamente hay una copia de innd ejecut�ndose todo el tiempo. Esto es muy beneficioso a nivel de rendimiento, ya que el demonio puede procesar todos los art�culos sin tener que preocuparse por el sincronismo de sus estados internos con otras copias de innd que se encuentran revolviendo la cola del servidor al mismo tiempo. Sin embargo, esta opci�n afecta el dise�o global del sistema de noticias. Debido a esto, es importante que las noticias entrantes sean procesadas lo m�s r�pidamente, es inaceptable que el servidor est� amarrado a tareas mundanas tales como darle acceso a un cliente de noticias v�a NNTP o descomprimir paquetes que arriban v�a UUCP. En consecuencia, este tipo de tareas deben ser separadas del servidor principal e implementadas por otros programas. Figura 23-1 intenta ilustrar las relaciones entre innd, las otras tareas locales, lo servidores y clientes de noticias remotos.

Hoy en d�a, NNTP es el medio de transporte m�s com�n en cuanto a noticias se refiere, y es el �nico que innd soporta directamente. Esto significa que innd continuamente esta escuchando el puerto 119 (TCP) y acepta las conexiones que utilizan el protocolo “ihave”.

Los art�culos que arriban por otro tipo de transporte que no sea NNTP son soportados de forma indirecta haciendo que otros procesos acepten los art�culos y se los reenv�en a innd v�a NNTP. Los paquetes que provienen de un enlace UUCP, por ejemplo, son tradicionalmente manejados por el programa rnews. Este programa descomprime los paquetes si es necesario, y separa cada uno de los art�culos; echo esto, se los ofrece a innd uno por uno.

Los clientes de noticias, pueden entregar un art�culo escrito por un usuario. Como el manejo de estos clientes merece especial atenci�n, volveremos a este tema un poco mas tarde.

Figura 23-1. Arquitectura de INN (simplificada)

Cuando recibe un art�culo, innd primero mira el identificador el mensaje (message ID) en el archivo history. Los art�culos y ocurrencias duplicados, son descartados y opcionalmente registrados en alg�n archivo de eventos (log). Lo mismo sucede con art�culos muy viejos o por ausencia de alg�n campo requerido, por ejemplo Subject:.[1] Si innd encuentra que el art�culo est� en orden, busca en el campo Newsgroups: para saber a que grupos de noticias fue remitido. Si alguno o todos estos grupos es encontrado en el archivo active, el art�culo es archivado en el disco. De otra manera, es archivado en un grupo especial llamado junk (Basura).

Los art�culos individuales son guardados en /var/spool/news, tambi�n llamado cola de noticias (news spool). Cada grupo de noticias tiene su propio directorio, en el cual cada art�culo es guardado por separado en un archivo. Los nombres de estos archivos son n�meros consecutivos, por ejemplo, un art�culo publicado en comp.risks ser� guardado como comp/risks/217. Al momento de guardarlo, innd busca el directorio donde deber�a ubicarse, si no se encuentra, lo crea autom�ticamente.

Aparte de guardar los art�culos localmente, Ud. puede reenviarlos a otros servidores. Esto es gobernado por el archivo newsfeeds donde est�n enlistados todos los servidores de menor jerarqu�a a los cuales se les deben pasar los art�culos.

De la misma forma que innd  maneja el proceso de entrada de los mensajes, maneja en una sola interfase, los que salen. El mismo puede manejar todo el transporte saliente. Sin embargo, necesita de varios motores que env�en los art�culos a los dem�s servidores. Todos los recursos para el env�o es apodado en forma colectiva canales (channels). Dependiendo de su prop�sito, un canal puede tener diferentes atributos que determinen exactamente que informaci�n debe pasarle innd.

Para un suministro NNTP saliente, por ejemplo, innd podr�a bifurcar el suministro hacia el programa innxmit al comienzo, y por cada art�culo pasarle el identificador, el tama�o, y el nombre del archivo hacia su entrada est�ndar, por otra parte, si se usa UUCP como suministro, innd puede escribir el tama�o del art�culo y su nombre en un registro especial, el cu�l es la cabecera de un proceso diferente a intervalos regulares en orden de crear los archivos por lotes y hacer la cola para el subsistema UUCP.

Adem�s de estos dos ejemplos, existen otros tipos de canales que no son estrictamente para suministros de salida. Estos son usados, por ejemplo, cuando se desea archivar ciertos grupos de noticias, o cuando se quiere generar informaci�n general. Esta informaci�n general es creada con la intenci�n de ayudar a los lectores de noticias a seguir el hilo de un tema de manera m�s eficaz. Los viejos lectores de noticias tienen que buscar en todos los art�culos de forma separada para obtener la informaci�n contenida en las cabeceras utilizada para seguir el hilo de los mensajes. Esto impone una pesada carga al servidor, especialmente cuando se usa NNTP; adicionalmente, es muy lento. [2] El mecanismo de informaci�n general alivia este problema pregrabando las cabeceras que son relevantes en un archivo separado (llamado .overview) por cada grupo de noticias. Esta informaci�n puede ser recogida por los lectores de noticias leyendo directamente desde el directorio donde se encuentra la cola de los mensajes, o usando el comando XOVER estando conectado v�a NNTP. INN tiene al demonio innd para suministrar todos los mensajes usando el comando overchan el cual es adosado al demonio a trav�s del canal. Luego veremos este m�todo cuando se discutan las configuraciones de los suministros de noticias.

Notas

[1]

Esto es indicado por la cabecera Date:; y el l�mite es usualmente dos semanas.

[2]

Hilar 1.000 art�culos cuando se conversa con un servidor activo puede tomar f�cilmente alrededor de cinco minutos, que solamente el m�s dedicado adicto a las noticias de Internet encontrar�a aceptable.