La idea de las noticias en red nació en 1979, cuando dos estudiantes de graduado, Tom Truscott y Jim Ellis, pensaron en usar UUCP para conectar ordenadores con el propósito de intercambiar información entre usuarios de UNIX. Instalaron una pequeña red de tres ordenadores en Carolina del Norte.

Inicialmente el tráfico de información era manejado por cierto número de shell scripts (mas tarde reescritos en C), pero que nunca fueron hechos públicos. Fueron rápidamente reemplazados por "A" news, la primera edición publica de programas para news.

"A" news no estaba diseñado para manejar mas que unos pocos artículos por grupo y día. Cuando el volumen de información continuo creciendo, fue reescrito por Mark Horton y Matt Glickman, quienes lo denominaron la versión "B" (también conocido como Bnews).

El primer lanzamiento publico de Bnews fue la versión 2.1, en 1982. Se fue expandiendo continuamente, conforme se le añadían nuevas prestaciones. La versión actual es Bnews 2.11.

Poco a poco se va quedando obsoleta, habiéndose pasado a INN su último mantenedor oficial.

Geoff Collyer y Henry Spencer reescribieron y lanzaron en 1987 otra nueva versión, conocida como versión "C" o Cnews . En el tiempo transcurrido desde entonces ha habido algunos parches para Cnews , siendo el más notable de ellos la Cnews Performance Release.

En sistemas que transportan un gran número de grupos, el consumo de recursos producido al ejecutar frecuentemente relaynews (el programa encargado de procesar los artículos) es bastante significativo. La Performance Release añade una opción que permite ejecutar relaynews en modo daemon, es decir, ejecutándose como tarea de fondo.

La Performance Release es la versión de Cnews que se incluye en la mayoría de las distribuciones de Linux actuales.

Todas las versiones hasta la "C" están principalmente diseñadas para utilizarse en redes UUCP, aunque igualmente pueden utilizarse en otros entornos. La transferencia eficiente de noticias sobre redes tipo TCP/IP, DECNet o similares, requiere otro planteamiento. Esta es la razón por la que en 1986 se introdujo el "Network News Transfer Protocol" (NNTP) o Protocolo de Transferencia de Noticias a través de la Red. Este protocolo esta basado en conexiones de red, y especifica cierto número de comandos para transferir los artículos de forma interactiva.

Hay bastantes aplicaciones basadas en el NNTP disponibles en la Red. Una de ellas es el paquete nntpd, de Brian Barber y Phil Lapsley, que puede usarse, entre otras cosas, para proporcionar un servicio de lectura de noticias a distintos nodos de una red local. nntpd fue diseñado para complementarse con Bnews o Cnews y darles prestaciones NNTP.

Otra aplicación NNTP diferente es INN, o Internet News. No es simplemente un interfaz, sino un sistema de noticias por derecho propio. Consta de un sofisticado demonio de noticias que es capaz de mantener varias conexiones NNTP simultaneas, y es por lo tanto, el software elegido por muchos servidores en Internet.

Una de las cosas más asombrosas de Usenet es que no forma parte de ninguna organización, ni tiene ninguna clase de autoridad central. De hecho, parte del saber popular de Usenet consiste en que excepto por una descripción técnica, no se puede definir que es, tan solo que no es. Si tiene Vd. a mano el excelente "Zen and the Art of the Internet" (disponible en Internet o a través de Prentice-Hall, ver [Kehoe92]), de Brendan Kehoe, encontrará una sorprendente lista de impropiedades de Usenet.

A riesgo de sonar tonto, podría definirse Usenet como la colaboración de servidores separados que intercambian noticias de Usenet. Para ser un servidor en Usenet, todo lo que hay que hacer es encontrar otro servidor Usenet y llegar a un acuerdo con sus propietarios y administradores para intercambiar noticias con ellos. Proporcionar artículos a otro servidor se denomina también alimentación o feeding, de donde se origina otro axioma común de Usenet: "Consigue alguien que te pase las noticias, y ya eres parte de Usenet".

La unidad fundamental de las noticias de Usenet es el artículo. Es un mensaje que un usuario escribe y "publica" en la red. Para posibilitar que los sistemas de noticias lo manejen, esta precedido de información administrativa, conocida como cabecera del artículo.

Es muy similar a la cabecera utilizada para el correo que se describe en el estándar RFC 822, y como ésta, consiste en varias líneas de texto, cada una de las cuales comienza con el nombre de un campo terminado en dos puntos, siguiendo después el valor de dicho campo.1

_____________________________________________
1 El formato de los mensajes de noticias de Usenet se especifica en la RFC 1036, "Standard for interchange of USENET messages".

Los artículos son enviados a uno o más grupos de noticias. Podrían considerarse a los grupos como foros para artículos relativos a una misma temática. Todos los grupos están organizados en una jerarquía, en la cual el nombre de cada grupo indica su lugar en la misma. Esto a menudo hace más fácil ver sobre que versa un grupo de noticias. Por ejemplo, todo el mundo puede deducir por el nombre que comp.os.linux.announce se usa para anuncios relativos a un sistema operativo para computadoras llamado Linux.

Estos artículos son intercambiados entre todos los servidores de Usenet a los que interese tener noticias de este grupo. Cuando dos servidores acuerdan intercambiar noticias, son libres de intercambiar cualquier grupo que deseen, y pueden incluso añadir sus propias jerarquías locales. Por ejemplo, groucho.edu puede tener un enlace de noticias con barnyard.edu, un gran servidor de noticias, y varios enlaces con servidores menores a los que alimenta con noticias. El Colegio Barnyard puede recibir todos los grupos de Usenet, mientras que la UGM solo quiere algunas jerarquías mayores como sci, comp, rec, etc.

Algunos servidores situados más abajo en esta cadena, digamos un servidor UUCP llamado brewhq, querrán incluso menos grupos, ya que no tendrán los suficientes recursos de hardware o de red. Por otro lado, brewhq puede querer recibir grupos de la jerarquía fj que la UGM no tiene. Por lo tanto, mantiene otro enlace con gargleblaster.com, quien tiene todos los grupos fj y se los pasa a brewhq. El flujo de noticias se muestra en la figura 16.1.

Las etiquetas en las flechas que parten de brewhq pueden requerir ciertas explicaciones. Por defecto, brewhq quiere que todas las noticias generadas localmente sean enviadas a groucho.edu. Sin embargo, ya que groucho.edu no lleva los grupos fj, no hay razón para enviar ningún artículo de estos grupos. Por tanto, la alimentación de brewhq a la UGM esta etiquetada all,!fj, lo que significa que se envían todos los grupos excepto los fj.

Hoy en día, Usenet ha crecido hasta alcanzar dimensiones enormes. Los servidores que llevan la totalidad de los grupos suelen tener que transferir unos sesenta megabytes por dia.2 Por supuesto esto requiere mucho mas que enredar con unos cuantos ficheros. Veamos como se las apañan la mayoría de sistemas UNIX para manejar las noticias.

Las noticias se distribuyen por la red de varias formas. El medio histórico solía ser UUCP, pero hoy en día el caudal principal es llevado por servidores permanentemente conectados a Internet. El algoritmo para encaminar se denomina inundación: cada servidor mantiene cierto número de enlaces con otros servidores. Cualquier artículo generado o recibido por el sistema local de noticias es enviado a estos servidores, a no ser que ya haya pasado por ellos. Se puede saber por que servidores ha pasado un artículo mirando el campo Path: de la cabecera. Este campo contiene una lista con todos los sistemas por los que el artículo ha pasado, separados por un signo de admiración.

_____________________________________________
2 Un momento: 60 Mb a 9600 bps, o sea, 60 millones por 1200, eso es. . . murmullo, murmullo,. . . ¡Eh! ¡Son 34 horas!

Figura 16.1: Flujo de noticias a través de la Universidad Groucho Marx

Para distinguir entre los artículos y reconocer los duplicados, los artículos de Usenet llevan un identificativo (especificado en el campo Message-Id: de la cabecera) que combina el nombre del servidor donde se publico y un número de serie "<num-serie@servidor>".

Cada vez que se procesa un artículo, el sistema de noticias registra su identificativo en un fichero (generalmente llamado history) con el que después se coteja cualquier nuevo artículo.

El flujo entre dos servidores puede ser limitado por dos criterios: por un lado, al artículo se le asigna una distribución (campo Distribution: de la cabecera) que puede ser usada para confinarlo a cierto grupo de servidores. Por otro lado, los grupos de noticias intercambiados pueden limitarse tanto en el sistema emisor como en el receptor. El conjunto de grupos y distribuciones que se permite transmitir a un sistema se suelen especificar en el fichero sys.

Debido al gran número de artículos, habitualmente se necesita mejorar el esquema anterior. En las redes UUCP, lo natural es recoger los artículos durante un cierto periodo de tiempo y combinarlos en un solo fichero, que posteriormente es comprimido y enviado a un sistema remoto. Esto se llama batching.3

Una técnica alternativa es la del protocolo ihave/sendme (tengo/envíame) que evita que los duplicados sean enviados en primer lugar, ahorrando ancho de banda. En vez de empaquetar todos los artículos en ficheros y enviarlos, solo se envían los identificativos de los mensajes en un gigantesco mensaje "ihave". El sistema remoto lee el mensaje, lo compara con su fichero histórico (history), y envía un mensaje "sendme" con la lista de artículos que quiere. De este modo, solo se enviaran estos artículos.

Por supuesto, el protocolo ihave/sendme solo tiene sentido si atañe a dos grandes sistemas que reciben noticias desde varios sitios independientes, y que se intercambian artículos entre sí con la suficiente frecuencia como para mantener un flujo de noticias eficiente.

Los servidores conectados a Internet generalmente se basan en programas bajo TCP/IP que usan el protocolo NNTP4, mencionado anteriormente. Con este protocolo se transfieren artículos entre servidores y se da acceso a Usenet a usuarios individuales en sistemas remotos.

NNTP contempla tres formas diferentes de transferir las noticias. Una es una versión en tiempo real de ihave/sendme, también conocida como empujar las noticias. La segunda técnica se denomina tirar de las noticias. El cliente solicita una lista de artículos de un grupo o jerarquía determinado que ha llegado al servidor después de una fecha especificada, y elige los que no puede encontrar en su fichero histórico. La tercera forma es para lectura interactiva, y permite al lector escoger artículos de grupos especificados, así como publicar artículos con cabeceras incompletas.

En cada sistema, las noticias se guardan en una estructura de directorios bajo /var/spool/news, cada artículo en un fichero separado, y cada grupo en un directorio separado. El nombre del directorio se crea a partir del nombre del grupo, donde los componentes del mismo son los componentes de la ruta. Así pues, los artículos de comp.os.linux.misc se guardan en /var/spool/news/comp/os/linux/misc. A cada artículo se le asigna un número según su orden de llegada. Este número sirve como nombre de fichero. El rango de artículos vigentes en un momento dado se guarda en un fichero llamado active, que al mismo tiempo sirve como lista de grupos disponibles en el sistema.

Puesto que el espacio en disco es un recurso finito,5 uno tiene que empezar a desechar los artículos de cierta antigüedad. Esto se denomina expiración. Generalmente, los artículos de un determinado grupo o jerarquía expiran al transcurrir un número determinado de días desde de su llegada. El autor puede modificar este valor especificando una fecha de expiración en el campo Expires: de la cabecera del artículo.

_____________________________________________
3 La regla de oro de las noticias de red, según Geoff Collyer: "Empaquetarás tus artículos".
4 Descrito en la RFC 977.
5 Alguna gente afirma que Usenet es un conspiración entre vendedores de módems y discos duros.