Arquitectura de INN (Manual administración de redes con Linux)

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:.2 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. 3 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.