Introducción

Usenet es una serie de redes abstractas la cual se encarga de gestionar la difusión de un sistema publico de mensajes, o bien de
"artículos". La idea base de Usenet es aquella de lograr un sistema automático de difusión de artículos entre un grupo de colaboradores, de modo de permitir a los usuarios leerlos y poder responderlos (conocido como "posting").

Inicialmente el mecanismo era muy simple; a intervalos regulares (una vez por día) cada nodo empaquetaba los artículos disponibles y los distribuía a sus nodos correspondientes, vía UUCP, los cuales seleccionaban la temática a recibir y eliminaban los artículos repetidos.

La evolución de Usenet permitió introducir tecnología de difusión mas dinámica, sobre todo con la creación del protocolo NNTP como parte de Internet. La complejidad de la historia de este sistema de mensajes trajo dificultades de configuración y administración del soft relativo. El soft utilizado para este mecanismo de difusión de artículos tiene su evolución en los programas Anews, Bnews, Cnews y el INN (InterNet News).

Dentro de esta secuencia cronológica, por el 1986, apenas aparece el Cnews se crea el estándar NNTP (Network News Tranfer Protocol) en el RFC 977. Esto permitió ubicar a Usenet como parte de Internet (a través de enchufes TCP)
usando lo conocido de SMTP. Cabe destacar que esto condeno al Cnews ya que este todavía usaba UUCP. Por otro lado el nacimiento del INN usaba un demonio que escuchaba en el puerto protegido 119 (al igual que SMTP en el 25) y automatizaba todos los procesos de conexión y trasferencia.

Organisacion de un sistema Usenet

Como se menciono, cada nodo recibe de otros nodos los artículos de su interés y este a su vez da servicio a otros y a su fuentes. Este
mecanismo se conoce en ingles como "feeding" (alimentar), esto permite sostener el flujo de artículos en Usenet. Las news de Usenet están organizadas en "grupos" (o bien grupos de discusión o "newsgroup") dentro de los cuales los usuarios pueden leer los artículos y remitir uno nuevo (posting). Estos grupos tienen una estructura gerarquica similar a la vista en Internet, o también, en los arboles de directorios. La idea base es esta: Puede existir el grupo "grano" el cual puede contener los subgrupos "granos.harina" y grano.siembra" y a su vez "grano.harina.producción" etc.

Obviamente el nombre de los grupos debe dar una idea de la temática a discutir. Volviendo a nuestra hilada anterior, el "feeding" es un mecanismo base de funcionamiento de Usenet. Asumamos a modo de ejemplo a la red global como un gigantesco sitio de servicio de "news". Esto esta representado (ver figura) por el nodo Usenet. De este extraen información
dos nodos mayoristas "news.super.abc" y "news.argentina.com" los cuales tienen una gran cantidad de grupos

    --------------------------------------------
    ---------------
    | Usenet |
    --------------
    * // * * \\ *
    // \\
    ------------------------- --------------------------
    news.super.abc news.argentina.com
    -------------------------- ---------------------------
    | | comp.* | |
    * ^ | it.* ^ | it.*
    | | alt.* | |
    | | | |
    --------------- comp.os.*--------------
    |------- |
    news.cosa.gov | |news.rosada.com
    |--- <--- |
    -------------- *,!it.* -------------
    -------------------------------------------

news.super.abc alimenta a news.cosa.gov con los grupos comp.* y alt.*, y a su vez es alimentado con cualquier articulo que remita (símbolo *) news.cosa.gov. En cambio news.argentina.com alimenta y es alimentado por artículos it.* de news.rosada.com. A su vez news.rosada.com alimenta con cualquier cosa menos it.* (!=menos el grupo) .... etc. etc.

Esto no involucra la existencia de nodos inteligentes sino que cada encabezado de cada articulo lleva información para el gestionado del trafico. Por supuesto el soft de gestión debe tener un mecanismo de memorizado de la historia del flujo que lo atraviesa, de caducidad de artículos (similar al ttl de IP). Por ejemplo el nodo news.rosada.com la primera vez que recibe un articulo (esto lo sabe de su archivo "history" en /usr/local/news/db o en /var/lib/news/etc/) adiciona al campo "Message-ID" del encabezado algo como lo siguiente

    Message-ID: ..... <36F130C4.2E242945@rosada.com>

y guarda el Message-ID en su "history". Esto permite descartar mensajes repetidos de otros servidores. Además el autor puede indicar un tiempo de caducidad en el campo "Expire:" (sino se usa el definido por defecto por el alimentador). Por otro lado se sabe la ruta seguida por el articulo viendo el campo "Path:", la forma de concatenación es similar a los "bang" de UUCP

    Path: ............!neo.argentina.com!pedo.rosada.com

evidentemente se coloca el nombre canónico, no su alias. Esto evita que el articulo sea reenviado a los nodos transmisores. El campo "Control:" permite el envío de comandos para la gestión de mensajes por parte del autor. Por supuesto el nodo receptor debe pedir autenticación del autor. Esto se regula en el archivo "control.ctl" en /usr/local/news/etc/control.ctl o en /etc/control.ctl. Para mas detalles sobre los campos ver RFC 1036.

Por ultimo existen un conjuntos de grupos administrativos "de facto" que no deben eliminarse (por tiempo de expiración) los cuales son:

1) control: Usado para gestionar artículos y conservación.
2) junk: Usado para recoger artículos de grupos faltantes.
3) test: Usado para diagnósticos y experimentos.
4) to: Usado para gestión entre soft gestores de servicio.

El archivo que contiene estos grupos esta ubicado en /usr/local/news/db o /var/lib/news y se llama "active". También contiene los
grupos usados por el nodo. Si un articulo no pertenece a un grupo declarado en "active" se crea y se da tiempo de expiración, si esta permitido el posting, y sino esta permitido se descarta.

Lic. Horacio Castellini

hcaste@lugro.org.ar