Servidor de noticias

Cada artículo de noticias contiene un conjunto completo de líneas de encabezado, pero comúnmente se usa el término "encabezados" para referirse a la base de datos de Resumen de Noticias . ^{[ 2 ]} El resumen es una lista de los encabezados más utilizados, junto con información adicional como el tamaño de los artículos, que normalmente se obtiene mediante el software cliente con el comando NNTP XOVER . Los resúmenes agilizan la lectura de un grupo de noticias tanto para el cliente como para el servidor, ya que eliminan la necesidad de abrir cada artículo individualmente para presentarlos en formato de lista.

Si se requieren encabezados que no sean de resumen, como cuando se usa un archivo de eliminación , aún puede ser necesario usar el método más lento de leer todos los encabezados completos del artículo. ^{[ 1 ]} Muchos clientes no pueden hacer esto y limitan el filtrado a lo que está disponible en los resúmenes. ^{[ 2 ]}

En el contexto de Usenet, la velocidad se refiere a la rapidez con la que un servidor puede entregar un artículo al usuario. El servidor al que se conecta el usuario suele formar parte de un clúster con numerosos servidores dedicados a diversas tareas. La velocidad de transmisión de datos dentro de este clúster es el primer factor que influye en la velocidad de entrega.

La velocidad de transmisión de datos en la granja de servidores puede verse seriamente limitada por las operaciones de los discos duros. La recuperación de artículos e información general puede sobrecargar los discos duros. Para solucionar este problema, se han desarrollado tecnologías de almacenamiento en caché y sistemas de almacenamiento de archivos cilíndricos.

Una vez que la granja de servidores puede enviar los datos a la red, el proveedor tiene un control limitado sobre la velocidad para el usuario. Dado que la ruta de red es diferente para cada usuario, algunos tendrán buenas rutas y los datos fluirán rápidamente. Otros usuarios tendrán enrutadores sobrecargados entre ellos y el proveedor, lo que provocará retrasos. En ese caso, lo único que puede hacer el proveedor es intentar redirigir el tráfico a través de una ruta alternativa. Si el proveedor de servicios de Internet (ISP) tiene conectividad limitada a la red, los cambios de enrutamiento podrían tener poco efecto.

Con frecuencia, un usuario puede reducir el impacto de los problemas de red utilizando múltiples conexiones. Algunos servidores permiten hasta 60 conexiones simultáneas, pero esto varía mucho según el proveedor. ^{[ 3 ]}

El tamaño de los artículos está limitado por la capacidad de cada servidor de noticias. Cuanto mayor sea el tamaño del artículo, más espacio ocupará y, por lo tanto, menor será la cantidad de artículos disponibles en cada servidor. Esto generalmente significa que un servidor puede funcionar con menos recursos, lo que resulta en un servidor más eficiente, pero ofrece menos artículos para que los usuarios accedan.

La retención se define simplemente como el tiempo que el servidor conserva los artículos. ^{[ 4 ]} Históricamente, la mayoría de los usuarios desean que la retención sea lo suficientemente larga como para no tener que acceder al servidor a diario, pero no excesivamente larga, ya que podría sobrecargar a los usuarios con ordenadores o conexiones de red lentas. ^{[ 1 ]} En la actualidad, las conexiones de alta velocidad, la gran capacidad de almacenamiento y las herramientas de búsqueda avanzadas permiten a los usuarios utilizar una retención extensa sin inconvenientes.

Generalmente, la retención se indica por separado para artículos de texto y binarios, aunque puede variar entre distintos grupos dentro de estas categorías. Los tiempos varían considerablemente según la capacidad de almacenamiento disponible en los servidores y el tráfico en constante aumento. En 2009, era común que los proveedores de noticias promedio tuvieran una retención de texto superior a 1000 días y una retención de binarios superior a 200 días. Los grandes proveedores de noticias ofrecían una retención de texto de hasta 2480 días y una retención de binarios de 850 días o más. Es importante tener en cuenta que el tiempo de retención varía entre los distintos grupos de noticias dentro de las categorías de texto y binarios. Actualmente, HW Media de Omicron es el servidor Usenet con la mayor retención de binarios, mientras que Google es el servidor Usenet con la mayor retención de textos.

Para los usuarios finales, puede resultar difícil medir con precisión la retención de un servidor. Un método común consiste en examinar los artículos más antiguos de un grupo y comprobar su fecha, pero esto no siempre es exacto. Algunos artículos de un grupo pueden conservarse durante más tiempo que otros, los artículos de servidores remotos no siempre llegan puntualmente y, en ocasiones, los encabezados de fecha son simplemente incorrectos. Para detectar estas anomalías, es necesario analizar una muestra de muchos o todos los artículos, preferiblemente de más de un grupo de noticias.

Los servidores de noticias no tienen almacenamiento ilimitado, por lo que solo pueden conservar las publicaciones durante un tiempo limitado antes de tener que eliminarlas para dejar espacio a nuevas publicaciones. Esto supone un problema particular para los grupos de noticias binarios , que transmiten grandes volúmenes de artículos.

En el caso de los servidores de noticias que ofrecen los proveedores de servicios de Internet (ISP) como parte de la suscripción de un usuario, la retención típica suele ser de tan solo 2 a 4 días. Para hacer frente al aumento del tráfico de Usenet, muchos proveedores recurren a un sistema híbrido, en el que los artículos antiguos que no se encuentran en el servidor del proveedor se solicitan a otro servidor con una retención más prolongada.

Dado el gran número de artículos que se transfieren entre servidores y el tamaño considerable de cada uno, no se garantiza su propagación completa a un único centro de datos. El término «completado» se utiliza para describir la capacidad de un servicio para gestionar el tráfico.

El principal obstáculo para calcular el porcentaje de finalización es la cantidad de artículos publicados. Al analizar un solo servidor, no se puede saber cuántos artículos se insertaron realmente en toda la red. Es posible que algunos artículos nunca salgan del servidor de origen o que no lleguen a la nube de tránsito. Los artículos muy grandes suelen descartarse y tienden a propagarse con menos eficacia que los más pequeños.

Una forma de medir la completitud es acceder a varios servidores y recuperar listas de artículos. Dado que los encabezados Message-ID: son nominalmente únicos en toda la red, la comparación de las listas suele ser una tarea sencilla. Las limitaciones prácticas de este tipo de medición incluyen la imposibilidad de obtener listas de todos los servidores del mundo, el hecho de que muchos servidores filtran el spam o aplican penalizaciones por incompleto en Usenet , y que algunos servidores ocultan la incompletitud ocultando conjuntos binarios multipartes con artículos faltantes. También es necesario tener en cuenta los tiempos de propagación y retención; un artículo puede simplemente no haber llegado aún a un servidor determinado, o puede haber estado presente pero ya haber caducado.

Todos los servidores Usenet se interconectan con uno o más servidores para intercambiar artículos. Ocasionalmente, aparecen nuevos servidores. Si bien existen varios recursos web que pueden ayudar a encontrar servidores interconectados, una opción más recomendable es el grupo de noticias news.admin.peering (portal de Google Groups).

A partir de 2020, los feeds de texto generalmente se pueden obtener de forma gratuita, mientras que los feeds binarios completos pueden ser gratuitos o de pago (dependiendo de la cantidad de artículos que cada servidor envíe al otro). Debido a la gran cantidad de datos en un feed Usenet binario+texto completo (que puede llegar a 30 terabytes por día) y los altos costos de transmitir esos datos a través de un proveedor de tránsito IP como Cogent , Telia o Zayo , la mayoría de los proveedores de Usenet solo participan en el peering binario cuando están interconectados en un punto de intercambio de Internet como AMS-IX , SIX o DeCIX .

Cuando el servidor almacena el cuerpo de un artículo, lo coloca en un área de almacenamiento en disco denominada genéricamente "spool". ^{[ 2 ]} Existen varias formas comunes en que se puede organizar el spool:

• El esquema de almacenamiento de un archivo por artículo es el más antiguo, todavía de uso común en servidores pequeños y replicado en muchos clientes. Su rendimiento depende directamente de la capacidad del sistema operativo subyacente para crear, eliminar y localizar archivos dentro de un directorio, y a menudo este esquema resulta insuficiente para gestionar el tráfico actual de Usenet. Sin embargo, ofrece la mayor flexibilidad para administrar la cantidad y la ubicación del almacenamiento utilizado por el servidor. Casi todo el software actual que utiliza este esquema almacena los artículos con el formato B News 2.10.
• El almacenamiento cíclico se ha vuelto cada vez más común desde la década de 1990. En este método, los artículos se agregan secuencialmente a grandes archivos contenedores indexados. Al llegar al final del archivo, se escriben nuevos artículos al principio, sobrescribiendo las entradas más antiguas. En algunos servidores, esta sobrescritura no se realiza, sino que se crean nuevos archivos contenedores a medida que se eliminan los antiguos. Las principales ventajas de este sistema incluyen requisitos de almacenamiento predecibles si se emplea un esquema de sobrescritura, y cierta independencia del rendimiento del sistema operativo. Sin embargo, existe menos flexibilidad para conservar los artículos por antigüedad en lugar de por espacio utilizado, y las herramientas tradicionales de manipulación de texto, como grep, son menos adecuadas para analizar estos archivos. Se puede ejercer cierto control sobre la longevidad de los artículos dirigiendo subconjuntos de los grupos de noticias a conjuntos específicos de archivos contenedores.
• En algunos casos, se utiliza una base de datos relacional o similar para almacenar el spool. Esto se observa con mayor frecuencia en el software de foros de Internet que también ofrece una interfaz NNTP.
• Algunos servidores, como INN , permiten utilizar varios esquemas de almacenamiento simultáneamente. También se han utilizado diversos esquemas de almacenamiento híbridos en servidores de noticias, incluyendo diferentes organizaciones del método de archivo por artículo, o contenedores más pequeños que albergan quizás 100 artículos cada uno.

Los servidores de tránsito modernos suelen utilizar NNTP para intercambiar noticias de forma continua a través de Internet y conexiones similares siempre activas. En el pasado, los servidores normalmente empleaban el protocolo UUCP , diseñado para conexiones de acceso telefónico intermitentes. Otros protocolos ad hoc , como el correo electrónico , son menos comunes. Los servidores de noticias normalmente se conectan con múltiples pares, y la redundancia ayuda a distribuir la carga y garantiza que no se pierdan artículos. Los sitios más pequeños, llamados nodos hoja , se conectan a otro servidor principal. ^{[ 2 ]}

Los artículos se enrutan en función de la información que se encuentra en las líneas de encabezado definidas en RFC 1036. De particular interés para un servidor de tránsito son:

• ID del mensaje : una clave única a nivel mundial
• Grupos de noticias : una lista de uno o más grupos de noticias donde se pretende que aparezca el artículo.
• Distribución – (opcional) un complemento de los grupos de noticias, utilizado para restringir la circulación de artículos.
• Fecha : la hora en que se creó el artículo.
• Ruta : una lista de los servidores por los que pasó un artículo en su camino hacia el servidor local.
• Caduca – (opcional) el momento en que se solicita que se elimine el artículo.
• Aprobado – (opcional) indica que un artículo ha sido aceptado para un grupo de noticias moderado.
• Control – (opcional) contiene solicitudes de comandos

En la mayoría de los casos, el servidor emisor controla el proceso de transferencia de artículos. Compara los grupos de noticias y la distribución de cada artículo recién llegado con un conjunto de patrones denominados fuentes de noticias , que enumeran cada servidor remoto y los grupos de noticias que su operador desea recibir. Algunos emisores también examinan la ruta; si el servidor receptor aparece en esta línea, no se ofrece. También se pueden agregar otras reglas locales. El emisor transmite los identificadores de mensaje (Message-IDs) de los artículos coincidentes al servidor receptor. El receptor indica qué identificadores de mensaje aún no ha almacenado localmente, y esos artículos se envían. ^{[ 2 ]}

El servidor receptor examina los artículos entrantes. Un mensaje se descarta normalmente si el ID del mensaje está duplicado por un artículo ya recibido (es decir, otro servidor lo envió mientras tanto), las líneas de fecha o caducidad indican que el artículo es demasiado antiguo, la sintaxis del encabezado parece no ser válida, falta el encabezado de aprobado para un grupo de noticias moderado o las reglas locales adicionales lo prohíben. La mayoría de los servidores también mantienen una lista de grupos de noticias activos. Si el encabezado de grupos de noticias de un artículo nuevo no coincide con la lista activa, puede descartarse o colocarse en un grupo de noticias especial de "basura". Una vez que el artículo se almacena, el servidor intenta retransmitirlo a cualquier servidor en su propia lista de fuentes de noticias. ^{[ 2 ]}

Los artículos con líneas de control reciben un tratamiento especial. Normalmente se archivan en grupos de noticias especiales de "control" y pueden provocar que el servidor ejecute automáticamente acciones excepcionales. Los comandos newgroupy rmgrouppueden crear o eliminar grupos de noticias; checkgroupsse puede utilizar para conciliar la lista activa local con un conjunto comúnmente aceptado; y cancellos comandos se utilizan para solicitar la eliminación de un artículo específico. ihavey sendmea veces se utilizan con UUCP para transmitir listas de Message-ID ofrecidos y deseados. Otros comandos ( version, sendsys, y uuname) son solicitudes de detalles de configuración del servidor. Antes se utilizaban para crear mapas de red, pero ahora están generalmente obsoletos. ^{[ 2 ]}

Un servidor lector es aquel que pone los artículos a disposición en el formato de directorio de disco jerárquico originado por B News 2.10, u ofrece los comandos NNTP o IMAP para su uso por los lectores de noticias. Un servidor lector también suele funcionar como servidor de tránsito, pero puede operar de forma independiente o servir como interfaz alternativa para un foro de Internet . Al recibir noticias, este tipo de servidor debe realizar los pasos adicionales de archivar los artículos en grupos de noticias y asignar números secuenciales dentro de cada grupo. Normalmente se añade una línea Xref , que enumera todos los grupos donde aparece el mensaje y los números secuenciales. A diferencia de los identificadores de mensaje, los números y el orden de los artículos difieren en cada servidor; pero los servidores relacionados pueden forzar la coincidencia operando en modo esclavo, reutilizando las líneas Xref de sus hermanos. Los servidores lectores también suelen mantener una base de datos de Resumen de Noticias (NOV) que permite a los lectores de noticias obtener rápidamente resúmenes de mensajes y presentarlos en forma de hilos. ^{[ 2 ]}

La mayoría de los servidores de lectura admiten la publicación, ya sea a través de NNTP o un programa especial de inews . Cuando se publica un artículo, el proceso es muy similar al de la recepción de noticias por parte de un servidor de tránsito, pero con comprobaciones adicionales. Para la publicación, el servidor normalmente completa las líneas faltantes de Ruta y ID del mensaje y verifica la sintaxis de los encabezados destinados a los lectores humanos, como De y Asunto . Si el artículo se publica en un grupo moderado, el servidor intentará enviarlo por correo electrónico al moderador del grupo de noticias si falta el encabezado Aprobado. En este punto también se suelen aplicar comprobaciones de identidad y filtros adicionales. ^{[ 2 ]}

Los sitios más pequeños con ancho de banda limitado pueden usar servidores de caché o de lectura . Estos cumplen la misma función que los servidores de noticias convencionales, pero actúan como lectores de noticias para intercambiar artículos con otros servidores. Los servidores híbridos ofrecen mayor flexibilidad al operador, ya que los grupos recibidos se pueden ajustar sin intervención manual. Además, pueden ser la única forma de obtener artículos de servidores remotos que no ofrecen alimentación convencional.

Debido a que los servidores híbridos suelen usar la función de publicación para enviar noticias, los encabezados de los artículos se reformatean mediante dicha función y puede perderse la información de seguimiento. Además, el proceso de descarga retardado puede generar una actividad excesiva en los servidores de lectura remotos. Por estas razones, el uso de servidores híbridos suele desaconsejarse o prohibirse sin un acuerdo previo. ^{[ 2 ]}