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. Ejecut�ndose como demonio se incrementa el rendimiento ya que s�lamente cuando se inicia se leer�n los ficheros de estado. Dependiendo del volumen del proveedor de noticias, algunos ficheros 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 s�lamente 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 �sto, es importante que las noticias entrantes sean procesadas lo m�s r�pidamente, es inaceptable que el servidor est� ocupado en tareas mundanas tales como darle acceso a un cliente de noticias v�a NNTP o descomprimir paquetes que lleguen por 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, los servidores y clientes de noticias remotos.
Hoy 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 est� escuchando el puerto 119 (TCP) y acepta las conexiones que utilizan el protocolo “ihave”.
Los art�culos que llegan 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 por NNTP. Los paquetes que provienen de un enlace UUCP, por ejemplo, son tradicionalmente manipulados por el programa rnews. Este programa descomprime los paquetes si es necesario, y separa cada uno de los art�culos; hecho 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 m�s tarde.
Cuando recibe un art�culo, innd primero mira el identificador el mensaje (message ID) en el fichero history. Los art�culos y ocurrencias duplicados, son descartados y opcionalmente registrados en alg�n fichero de registro. 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 qu� grupos de noticias fue remitido. Si alguno o todos estos grupos se encuentran en el fichero active, el art�culo se archiva en el disco. En caso contrario, se archiva en un grupo especial llamado junk (Basura).
Los art�culos individuales se guardan en /var/spool/news, tambi�n llamado cola de noticias (news spool). Cada grupo de noticias tiene su propio directorio, en el cu�l cada art�culo se guarda por separado en un fichero. Los nombres de estos ficheros son n�meros consecutivos, por ejemplo, un art�culo publicado en comp.risks se guardar� como comp/risks/217. En el 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, puede reenviarlos a otros servidores. Esto se controla por el fichero newsfeeds donde est�n listados todos los servidores de menor jerarqu�a a los cu�les se les deben pasar los art�culos.
De la misma forma que innd gestiona el proceso de entrada de los mensajes, gestiona en una sola interfaz, los que salen. �l mismo puede gestionar todo el transporte saliente. Sin embargo, necesita varios motores que env�en los art�culos a los dem�s servidores. Todos los recursos para el env�o se llaman en forma colectiva “canales[2]”. Dependiendo de su prop�sito, un canal puede tener diferentes atributos que determinen exactamente qu� 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 fichero 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 ficheros 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. �stos son usados, por ejemplo, cuando se desea archivar ciertos grupos de noticias, o cuando se quiere generar informaci�n general. Esta informaci�n general se crea con la intenci�n de ayudar a los lectores de noticias a seguir el hilo de un tema de manera m�s eficaz. Los antiguos 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. [3] El mecanismo de informaci�n general alivia este problema pregrabando las cabeceras que son relevantes en un fichero 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 la instrucci�n XOVER estando conectado v�a NNTP. INN tiene al demonio innd para suministrar todos los mensajes usando la instrucci�n overchan la cu�l se adosa al demonio a trav�s del canal. Luego veremos este m�todo cuando se discutan las configuraciones de los suministros de noticias.