Resumen

  • RFC 977 trató el duplicado como un coste dependiente del enlace: dos servidores interactivos podían comparar lo que ya tenían antes de enviar el texto.
  • El mismo RFC mantuvo el envío y descarte de duplicados en enlaces UUCP de una sola transacción, donde un lote podía llegar antes que una negociación.

En febrero de 1986, Brian Kantor y Phil Lapsley publicaron RFC 977, la propuesta del Network News Transfer Protocol. Su idea más reveladora no era que un transporte debiera imponerse en Usenet. El coste de un duplicado dependía de la conexión por la que viajaba. En un flujo interactivo, dos equipos podían comparar sus colecciones y decidir qué enviar. En un enlace que se abría una vez al día, conversar para tomar esa decisión podía tardar más que transferir el duplicado.

El método tradicional que describe el RFC propagaba las noticias mediante inundación: cada sitio enviaba sus artículos nuevos a los sitios alimentados por él, que a su vez los reenviaban a otros. Un servidor con dos fuentes podía recibir el mismo artículo dos veces. En una transferencia programada o de una sola transacción, el emisor no podía detenerse cómodamente para preguntar si el receptor ya tenía el artículo. El receptor aceptaba el lote y eliminaba las copias repetidas después. Se gastaban tiempo y capacidad, pero la sesión era sencilla.

NNTP añadió una conversación previa. El cliente podía preguntar qué grupos nuevos había, consultar los identificadores de los artículos de los grupos que le interesaban y solicitar los que aún no tenía. En sentido inverso, un servidor podía comunicar a su vecino qué artículos acababa de recibir; el otro distinguía cuáles ya estaban en su colección y cuáles debía enviar. El cuerpo del artículo dejó de ser la primera prueba de que el mensaje había cruzado el enlace: antes se comparaban identificadores.

La elección dependía del trayecto. RFC 977 dice que los equipos bien conectados por una red local u otra red rápida podían distribuir noticias con más eficiencia que mediante métodos tradicionales como UUCP. Pero también explica por qué tenían sentido los lotes de UUCP: en una conexión de una sola transacción, sobre todo si solo se usaba una vez al día, enviar todos los artículos y descartar luego los duplicados podía reducir el tiempo total. Negociar de forma interactiva no era automáticamente más barato por transmitir menos bytes.

El RFC describe otro uso que conviene separar del intercambio entre sitios. Una universidad o empresa podía guardar las noticias en un spool central y permitir que los puestos de trabajo las consultaran por la red local. Los lectores elegían artículos de un almacenamiento compartido, sin guardar otra copia completa en cada equipo. Un servidor intermedio podía almacenar temporalmente los artículos consultados. Era una solución de acceso y almacenamiento local; no significaba que todos los sitios de Usenet compartieran una única base central.

RFC 850 ya había normalizado el formato de los artículos de USENET, pero dejaba flexibles los métodos de transmisión: cada sitio podía escoger hardware, software y envíos por lotes. RFC 977 trabajó dentro de esa diversidad. Especificó un flujo para consultar, recuperar, publicar e intercambiar artículos, a la vez que reconocía la ventaja de otro transporte en líneas intermitentes. La propuesta era condicional: usar la conversación cuando la red pudiera sostenerla y mantener los lotes cuando ahorrasen tiempo.

Los documentos prueban una intención de diseño, no una migración universal. RFC 977 no indica qué proporción de Usenet adoptó NNTP en 1986, cuánto ancho de banda se ahorró ni si cada implementación evitó los duplicados. Su aportación es más concreta: la selección pasó a ser un intercambio entre servidores, de modo que el receptor podía decir qué quería y qué ya tenía antes de que el emisor enviara otra copia.

Fuentes: RFC 977, Network News Transfer Protocol; RFC 850, formato de intercambio de mensajes USENET; RFC 1036, formato de intercambio de mensajes USENET.