Actualmente, Usenet ha crecido a enormes dimensiones. Los servidores que llevan todos los grupos usualmente transfieren algo como 60 MB diarios. [1] Por supuesto, esto requiere mucho m�s que mezclar ficheros. Vamos a dar una mirada a la manera en la mayor�a de los sistemas Unix manejan las noticias de Usenet.
Las noticias empiezan cuando los usuarios crean y publican los art�culos. Cada usuario introduce un mensaje en una aplicaci�n especial llamada lector de noticias, el cual lo formatea apropiadamente para su transmisi�n al servidor de noticias local. En entornos Unix el lector de noticias normalmente emplea la instrucci�n inews para transmitir art�culos al servidor de noticias usando el protocolo TCP/IP. Sin embargo, tambi�n es posible escribir el art�culo directamente en un fichero dentro de un directorio especial llamado cola de noticias. Una vez que la publicaci�n se entrega al servidor local de noticias, �ste toma la responsabilidad de entregar el art�culo a otros usuarios de noticias.
Las noticias son distribuidas a trav�s de la red por varios transportes. El medio acostumbraba a ser UUCP, pero hoy el tr�fico principal se lleva por sitios de Internet. El algoritmo de encaminamiento usado se llama flooding.[2] Cada sitio mantiene varios enlaces (news feeds) a otros servidores. Cualquier art�culo generado o recibido por el sistema de noticias local es reenviado a ellos, a menos que ya haya pasado por ellos, en cuyo caso ser� descartado. Un sitio puede averiguar todos los sitios por los que ha pasado el art�culo observando el campo Path: de la cabecera. Este campo contiene una lista de todos los sistemas que ha atravesado el art�culo, separados por un signo de admiraci�n[3].
Para distinguir los art�culos y reconocer los duplicados, los art�culos de Usenet llevan un identificador de mensajes, (especificado en el campo Message-Id: de la cabecera), el cu�l es una combinaci�n del nombre del servidor y un n�mero de serie. <serial@site >. Para cada art�culo procesado, los sistemas de noticias registran su identificador en un fichero llamado history contra el cual se cotejan los art�culos reci�n llegados.
El flujo entre dos servidores cualquiera puede ser limitado por dos criterios. Uno, al art�culo se le asigna una distribuci�n (en el campo Distribution: de la cabecera), que puede ser usado para confinarlo dentro de un determinado grupo de servidores. Por otro lado, los grupos de noticias intercambiados pueden ser limitados por ambos sistemas, el remitente y el receptor. El conjunto de grupos de noticias y distribuciones que le es permitido transmitir a un servidor se mantienen usualmente en el fichero sys.
El n�mero de art�culos normalmente requiere que se hagan mejoras al esquema anterior. En redes UUCP los sistemas recogen los art�culos en un periodo de tiempo y los combinan en un �nico fichero el cu�l es comprimido y enviado al servidor remoto. Esto se llama procesado por lotes[4].
Una t�cnica alternativa es la del protocolo ihave/sendme que previene la transmisi�n de art�culos duplicados en primer lugar, as� se ahorra ancho de banda de la red. En lugar de poner todos los art�culos en un bloque y enviarlo, s�lo se env�an al servidor remoto los IDs combinados en un gran mensage llamado “ihave”. El servidor remoto lee este mensaje, lo compara con su fichero "history" y retorna la lista de art�culos que quiere en un mensaje “sendme”. S�lo los art�culos requeridos son enviados.
Claro, el protocolo ihave/sendme s�lo tiene sentido si involucra dos grandes servidores que reciben noticias de varias fuentes independientes entre s�, y que intercambian noticias con la frecuencia suficiente como para generar un flujo de noticias eficiente.
Los servidores de Internet generalmente conf�an en el software basado en TCP/IP que usa el Protocolo de Transferencia de Noticias (NNTP). NNTP se describe en el RFC-977; el cu�l es responsable de transferir las noticias entre servidores nuevos y provee acceso a Usenet a usuarios individuales en nodos remotos.
Se conocen tres maneras diferentes de transferir las noticias con NNTP. Una es la versi�n en tiempo real de ihave/sendme, tambi�n conocida como push[5] las noticias. La segunda t�cnica es llamada pull[6] las noticias, en la cu�l el cliente requiere una lista de art�culos de un grupo de noticias o jerarqu�a determinado que han llegado al servidor despu�s de una fecha especificada y elige aquellas que no encuentra en su fichero "history". La tercera t�cnica es la lectura interactiva de noticias y le permite a usted o a su lector de noticias recuperar art�culos de un grupo especificado, tambi�n colocar art�culos con la informaci�n de cabecera incompleta.
Cada servidor guarda las noticias en una jerarqu�a 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 construye a partir del nombre del grupo, cuyos componentes son los componentes de la ruta. De este modo, los art�culos de comp.os.linux.misc se guardan en /var/spool/news/comp/os/linux/misc. Los art�culos de un grupo reciben n�meros de acuerdo a su orden de llegada. Este n�mero sirve como nombre del fichero. El rango de los n�meros de los ficheros vigentes se conserva en un fichero llamado active el cual al mismo tiempo sirve como la lista de grupos del sistema.
Toda vez que el espacio en disco es un recurso finito, se tiene que empezar a desechar art�culos despu�s de un tiempo. [7] A esto se llama expiraci�n. Usualmente los art�culos de un determinado grupo y jerarqu�a expiran al cabo de un n�mero fijo de d�as despu�s de llegar. El autor puede invalidar esta fecha de expiraci�n especificando una fecha de expiraci�n en el campo Expires: de la cabecera del art�culo.
Ahora usted tiene bastante informaci�n para escoger qu� leer despu�s. Los usuarios de UUCP pueden leer sobre C-News en Cap�tulo 21. Si usted est� usando una red TCP/IP, lea acerca de NNTP en Cap�tulo 22. Si necesita transferir vol�menes moderados de noticias sobre TCP/IP, el servidor descrito en ese cap�tulo puede ser suficiente. Para instalar un servidor de noticias pesado que pueda manejar grandes vol�menes de material, vaya a leer acerca de Internet News en Cap�tulo 23.
[1] | Espera un minuto: 60 MB a 9,600 bps, son 60 millones mutiplicados por 1024, eso es �… mutter, mutter… Eh! eso es 34 horas! |
[2] | N. del T.: inundaci�n. |
[3] | N. del T.: notaci�n bang-path |
[4] | batching |
[5] | empujar |
[6] | tirar |
[7] | Algunas persontas dicen que Usenet es una conspiraci�n entre vendedores de modems y discos duros. |