Los lectores de noticias que se ejecutan en la misma máquina junto con el servidor (o que tienen montado el directorio donde se encuentra la cola del servidor de noticias vía NFS) pueden leer los artículos de forma directa. Para remitir un artículo compuesto por un usuario, el lector, invoca al programa inews el cuál agrega cualquier cabecera que esté faltando y se lo envía al demonio vía NNTP.
Alternativamente, los lectores pueden acceder al servidor remoto vía NNTP. Este tipo de conexión se gestiona de forma diferente por los proveedores de noticias basados en NNTP, para no dejar colgado el demonio. En el momento que un lector de noticias se conecta al servidor NNTP, innd bifurca la conexión hacia un programa llamado nnrpd[1], el cual maneja la sesión y libera a innd para que realice tareas más importantes (recibir noticias nuevas, por ejemplo). Usted estará admirado al ver cómo el proceso innd puede distinguir entre un proveedor de noticias entrante y la conexión de un cliente. La respuesta es simple: el protocolo NNTP requiere que el cliente emita la orden mode reader[2]después de conectarse al servidor; cuando esta orden se recibe, el servidor activa el proceso nnrpd y le entrega el control de la conexión, luego retorna a su habitual estado de escucha, esperando conexiones de otros servidores de noticias. Solía haber un lector de noticias basado en DOS que no estaba configurado para hacer esto, y fallaba de forma miserable cuando intentaba comunicarse con INN, porque innd no reconocía ninguno de las órdenes usadas para leer noticias si no sabía que la conexión era desde un lector de noticias
Volveremos al tema de cómo los lectores de noticias pueden acceder a INN en el capítulo «Controlando el acceso de los lectores».
[1] | El nombre aparentemente es una sigla de NetNews Read & Post Daemon |
[2] | modo lectura |