__ / \ /|oo \ (_| /_) _`@/_ \ _ | | \ \\ | (*) | \ )) ______ |__U__| / \// / FIDO \ _//|| _\ / (________) (_/(_|(____/ (c) John Madill
FidoNet es una red informática mundial que se utiliza para la comunicación entre sistemas de tablones de anuncios (BBS). Utiliza un sistema de almacenamiento y reenvío para intercambiar mensajes privados (correo electrónico) y públicos (foro) entre los BBS de la red, así como otros archivos y protocolos en algunos casos.
El sistema FidoNet se basaba en varios programas pequeños que interactuaban, de los cuales solo uno necesitaba ser adaptado para soportar otro software BBS. FidoNet era una de las pocas redes que era compatible con casi todo el software BBS, así como con varios servicios en línea que no eran BBS . Esta construcción modular también permitió que FidoNet se actualizara fácilmente a nuevos sistemas de compresión de datos , lo que era importante en una era en la que se utilizaban comunicaciones basadas en módem a través de enlaces telefónicos con altos costos de llamadas de larga distancia .
La rápida mejora de la velocidad de los módems a principios de los años 90, combinada con la rápida disminución del precio de los sistemas informáticos y de almacenamiento, hizo que los BBS fueran cada vez más populares. A mediados de los años 90 había casi 40.000 sistemas FidoNet en funcionamiento y era posible comunicarse con millones de usuarios de todo el mundo. Sólo UUCPNET se acercaba en términos de amplitud o número; la base de usuarios de FidoNet superaba con creces a otras redes como BITNET . [1]
La amplia disponibilidad de conexiones a Internet de bajo costo a partir de mediados de los años 1990 redujo la necesidad del sistema de almacenamiento y reenvío de FidoNet, ya que se podía acceder a cualquier sistema del mundo por el mismo costo. La marcación directa a sistemas BBS locales disminuyó rápidamente. Aunque FidoNet se ha reducido considerablemente desde fines de los años 1990, ha seguido utilizándose incluso hoy [2] a pesar de que la conectividad a Internet se está generalizando.
Hay dos relatos principales sobre el desarrollo de FidoNet, que difieren sólo en pequeños detalles.
En la Navidad de 1983, Tom Jennings empezó a trabajar en un nuevo sistema de tablón de anuncios que se convertiría en Fido BBS. Se lo llamó "Fido" porque el hardware que lo formaba era "una auténtica mezcla". [3] Jennings instaló el sistema en San Francisco a principios de 1984. Otro de los primeros usuarios fue John Madill, que intentaba instalar un sistema similar en Baltimore con su Rainbow 100. Fido empezó a extenderse a nuevos sistemas y, con el tiempo, Jennings empezó a llevar una lista informal de sus números de teléfono, y Jennings se convirtió en el número uno y Madill en el número dos. [4]
Jennings publicó la primera versión del software FidoNet en junio de 1984. A principios de 1985 escribió un documento explicando el funcionamiento de FidoNet, junto con una breve parte sobre la historia del sistema. En esta versión, FidoNet se desarrolló como una forma de intercambiar correo entre los dos primeros sistemas BBS de Fido, el de Jennings y el de Madill, para "ver si se podía hacer, simplemente por diversión". Esto se admitió por primera vez en Fido V7, "en algún momento de junio de 1984 aproximadamente". [5] [6] [7]
A principios de 1984, Ben Baker estaba planeando iniciar un BBS para el club de computación que se estaba formando en la división automotriz McDonnell Douglas en St. Louis . Baker era parte del grupo de interés especial CP/M dentro del club. [8] Tenía la intención de utilizar el sistema CBBS , que se basaba en CP/M , y fue a buscar una máquina para ejecutarlo. El presidente del club le dijo a Baker que DEC les daría un ordenador Rainbow 100 en préstamo indefinido, por lo que hizo planes para mover el CBBS a esta máquina. El Rainbow contenía dos procesadores , un Intel 8088 y un Zilog Z80 , lo que le permitía ejecutar MS-DOS y CP/M , con el BBS ejecutándose en este último. Cuando llegó la máquina, se enteraron de que el lado Z80 no tenía acceso a los puertos de E/S , por lo que el CBBS no podía comunicarse con un módem . Mientras buscaba software que pudiera ejecutarse en el lado MS-DOS del sistema, Baker se enteró de Fido a través de Madill. [4]
El software Fido requería cambios en los controladores seriales para funcionar correctamente en Rainbow. Se inició un esfuerzo de adaptación, en el que participaron Jennings, Madill y Baker. Esto provocó que todos los involucrados acumularan considerables gastos de larga distancia , ya que todos se llamaban entre sí durante el desarrollo o llamaban a los BBS de los demás para dejar mensajes de correo electrónico. Durante una de esas llamadas "en mayo o principios de junio", Baker y Jennings hablaron sobre lo fantástico que sería si los sistemas BBS pudieran llamarse entre sí automáticamente, intercambiando correo y archivos entre ellos. [4] Esto les permitiría redactar correo en sus máquinas locales y luego entregarlo rápidamente, en lugar de llamar y escribir el mensaje mientras están en una conexión telefónica de larga distancia. [4]
Jennings respondió llamando al sistema de Baker esa noche y cargando una nueva versión del software que constaba de tres archivos: FIDO_DECV6, una nueva versión del programa BBS, FIDONET, un nuevo programa, y NODELIST.BBS, un archivo de texto. La nueva versión de FIDO BBS tenía un temporizador que hacía que saliera a una hora específica, normalmente de noche. Al salir, ejecutaba el programa FIDONET independiente. NODELIST era la lista de sistemas Fido BBS, que Jennings ya había estado compilando. [4]
El programa FIDONET era lo que más tarde se conocería como un programa de correo . El software FIDO BBS se modificó para utilizar un campo numérico no utilizado anteriormente en los encabezados de los mensajes para almacenar un número de nodo para la máquina a la que se debía enviar el mensaje. Cuando se ejecutaba FIDONET, buscaba en la base de datos de correo electrónico cualquier mensaje con un número en este campo. FIDONET recopilaba todos los mensajes para un número de nodo en particular en un archivo conocido como paquete de mensajes . Después de que se generaran todos los paquetes, uno para cada nodo, el programa FIDONET buscaba el número de teléfono del nodo de destino en NODELIST.BBS y llamaba al sistema remoto. Siempre que FIDONET se estuviera ejecutando en ese sistema, los dos sistemas se comunicarían y, si esto tenía éxito, el sistema que realizaba la llamada cargaría su paquete, descargaría un paquete de retorno si lo hubiera y se desconectaría. Luego, FIDONET descomprimiría el paquete de retorno, colocaría los mensajes recibidos en la base de datos del sistema local y pasaría al siguiente paquete. Cuando no quedaban paquetes restantes, FIDONET salía y ejecutaba el programa FIDO BBS. [9]
Para reducir los costos de larga distancia, los intercambios de correo se programaron para funcionar tarde en la noche, normalmente a las 4 a. m. [5] Esto más tarde se conocería como la hora de correo nacional , [10] y, más tarde aún, como la hora de correo de zona .
En junio de 1984, la versión 7 del sistema ya estaba funcionando en producción y se añadían nodos rápidamente a la red. En agosto, había casi 30 sistemas en la lista de nodos, 50 en septiembre y más de 160 en enero de 1985. A medida que la red crecía, el mantenimiento de la lista de nodos se volvió prohibitivo y los errores eran comunes. En estos casos, la gente empezaba a recibir llamadas telefónicas a las 4 de la mañana, de un interlocutor que no decía nada y luego colgaba. En otros casos, el sistema se incluía en la lista antes de estar en funcionamiento, lo que daba lugar a llamadas de larga distancia que no conseguían nada. [5]
En agosto de 1984, Jennings entregó el control de la lista de nodos al grupo de St. Louis, compuesto principalmente por Ken Kaplan y Ben Baker. Kaplan había conocido a Fido como parte de la búsqueda de una solución BBS para su empresa, que trabajaba con ordenadores DEC y le habían proporcionado un ordenador Rainbow y un módem USRobotics de 1200 bit/s . [11] A partir de entonces, para unirse a FidoNet era necesario configurar su sistema y utilizarlo para enviar un mensaje de correo electrónico a un sistema especial, el Nodo 51. El mensaje contenía información de contacto necesaria. Si este mensaje se transmitía correctamente, se aseguraba de que al menos una parte del sistema funcionaba correctamente. El equipo de la lista de nodos respondía entonces con otro mensaje de correo electrónico al sistema en cuestión, que contenía el número de nodo asignado. Si la entrega se realizaba correctamente, se consideraba que el sistema funcionaba correctamente y se añadía a la lista de nodos. [5] La primera lista de nodos nueva se publicó el 21 de septiembre de 1984. [4]
El crecimiento continuó acelerándose y, en la primavera de 1985, el sistema ya había alcanzado su límite de 250 nodos. Además de los límites de crecimiento de lo que era claramente un sistema popular, el mantenimiento de la lista de nodos siguió siendo cada vez más laborioso. [4]
También se observó que los sistemas Fido estaban generalmente agrupados: de los 15 sistemas que funcionaban a principios de junio de 1984, 5 de ellos estaban en St. Louis. [4] Un usuario del sistema de Jennings en San Francisco que dirigiera correos electrónicos a diferentes sistemas en St. Louis haría que se hicieran llamadas a cada uno de esos BBS por turno. En los Estados Unidos, las llamadas locales normalmente eran gratuitas y en la mayoría de los demás países se cobraban a una tarifa baja. Además, el establecimiento de la llamada inicial, generalmente el primer minuto de la llamada, normalmente se facturaba a una tarifa más alta que continuar una conexión existente. Por lo tanto, sería menos costoso entregar todos los mensajes de todos los usuarios de San Francisco a todos los usuarios de St. Louis en una sola llamada. Los paquetes eran generalmente lo suficientemente pequeños como para ser entregados en uno o dos minutos, por lo que entregar todos los mensajes en una sola llamada podría reducir en gran medida los costos al evitar múltiples cargos en el primer minuto. Una vez entregado, el paquete se dividiría en paquetes separados para los sistemas locales y se entregaría utilizando múltiples llamadas locales gratuitas.
El equipo se decidió por el concepto de añadir un nuevo número de red basado en la idea de los códigos de área . [N 1] Una dirección de red completa consistiría ahora en el par de número de red y de nodo, que se escribirían con una barra entre ellos. Todo el correo que viajase entre redes se enviaría primero a su host de red local , alguien que se ofreciera voluntariamente a pagar los cargos de larga distancia. Ese único sitio recogería todo el correo de red de todos los sistemas de su red, luego lo volvería a empaquetar en paquetes individuales destinados a cada red. Luego, llamarían a los sitios de administración de red necesarios y les entregarían el paquete. Ese sitio procesaría el correo de forma normal, aunque se garantizaría que todos los mensajes del paquete fueran llamadas locales. [4]
La dirección de red se colocaba en un campo no utilizado en la base de datos de mensajes de Fido, que anteriormente siempre contenía un cero. Los sistemas que ejecutaban versiones existentes del software ya ignoraban los campos que contenían la nueva dirección, por lo que continuarían funcionando como antes; cuando detectaran un mensaje dirigido a otro nodo, lo buscarían y llamarían a ese sistema. Los sistemas más nuevos reconocerían el número de red y, en su lugar, enviarían ese mensaje al host de red. Para garantizar la compatibilidad con versiones anteriores, los sistemas existentes conservaron sus números de nodo originales durante este período. [4]
Una gran ventaja del nuevo esquema fue que los números de nodo ahora eran únicos solo dentro de su red, no globalmente. Esto significó que el límite anterior de 250 nodos había desaparecido, pero por diversas razones este límite se limitó inicialmente a aproximadamente 1200. Este cambio también delegó el mantenimiento de las listas de nodos a los hosts de la red, quienes luego enviaron listas actualizadas al Nodo 51 para que se recopilaran en la lista maestra. El grupo de St. Louis ahora solo tenía que mantener su propia red local y hacer el trabajo básico para compilar la lista global. [4]
En una reunión celebrada en la sala de estar de Kaplan en St. Louis el 11 de abril de 1985 [N 2], las distintas partes acordaron todos los detalles del nuevo concepto. Como parte de esta reunión, también añadieron el concepto de región , un nivel puramente administrativo que no formaba parte del esquema de direccionamiento. Los hosts regionales se encargarían de cualquier rezagado en los mapas de red, sistemas remotos que no tenían hosts de red locales. A continuación, dividieron los EE. UU. en diez regiones que, según su opinión, tendrían poblaciones aproximadamente iguales. [4]
En mayo, Jennings ya tenía en funcionamiento las primeras versiones del nuevo software. Estas primeras versiones especificaban el enrutamiento de forma manual a través de un nuevo archivo ROUTE.BBS que enumeraba los hosts de red para cada nodo. Por ejemplo, un operador podría querer reenviar todo el correo a St. Louis a través de un solo nodo, el nodo 10. ROUTE.BBS incluiría entonces una lista de todos los sistemas conocidos en esa área, con instrucciones para reenviar el correo a cada uno de esos nodos a través del nodo 10. Este proceso fue semiautomatizado posteriormente por el programa NODELIST de John Warren. [12] Con el tiempo, esta información se incorporó a versiones actualizadas del formato de lista de nodos y el archivo ROUTES ya no se utiliza. [13]
Se lanzó una nueva versión de FIDO y FIDONET, 10C, que contenía todas estas características. El 12 de junio de 1985, el grupo central lanzó 10C y la mayoría de los sistemas Fido se actualizaron en pocos meses. [12] El proceso fue mucho más sencillo de lo que nadie hubiera imaginado y muy pocos nodos tuvieron problemas. [4]
En algún momento durante la evolución de Fido, se añadieron archivos adjuntos al sistema, lo que permitía hacer referencia a un archivo desde un mensaje de correo electrónico. Durante el intercambio normal entre dos instancias de FIDONET, todos los archivos adjuntos a los mensajes en los paquetes se entregaban después de que el paquete en sí se hubiera cargado o descargado. No está claro cuándo se añadió esto, pero ya era una característica del sistema básico cuando se publicó la versión del 8 de febrero de 1985 del documento de estándares de FidoNet, por lo que se añadió muy pronto en la historia de Fido.
En una reunión de sysop en Dallas, se planteó la idea de que sería bueno que hubiera alguna manera de que los sysops publicaran mensajes que se compartirían entre los sistemas. [14] En febrero de 1986, Jeff Rush, uno de los miembros del grupo, presentó un nuevo programa de correo que extraía mensajes de foros públicos que el sysop seleccionaba, de forma similar a la forma en que el programa de correo original manejaba los mensajes privados. El nuevo programa se conocía como tosser/scanner . El tosser producía un archivo que era similar (o idéntico) a la salida del escaneo normal de netmail, pero estos archivos se comprimían y se adjuntaban a un mensaje de netmail normal como archivo adjunto. Luego, este mensaje se enviaba a una dirección especial en el sistema remoto. Después de recibir netmail de forma normal, el escáner del sistema remoto buscaba estos mensajes, los descomprimía y los colocaba en el mismo foro público en el sistema original. [10]
De esta manera, el sistema de Rush implementó un sistema de almacenamiento y reenvío de mensajes públicos similar a Usenet , pero basado en el sistema FidoNet y alojado por él. El primer foro de correo electrónico de este tipo fue uno creado por los sysops del área de Dallas para discutir negocios, conocido como SYSOP. Otro llamado TECH le siguió pronto. Pronto le siguieron varios ecos públicos , incluidos GAYNET y CLANG. Estos generaron cientos de nuevos ecos y llevaron a la creación de la Echomail Conference List (Echolist) por Thomas Kenny en enero de 1987. [15] Echomail produjo foros compartidos que abarcaban todo el mundo y su volumen de tráfico superó rápidamente al sistema de correo electrónico original. A principios de la década de 1990, el correo electrónico de eco transportaba más de 8 MB de tráfico de mensajes comprimidos al día, muchas veces más cuando no estaban comprimidos. [10]
El correo electrónico de eco no utilizaba necesariamente las mismas vías de distribución que el correo electrónico normal, y el enrutamiento de distribución se almacenaba en un archivo de configuración independiente, no muy distinto del ROUTES.BBS original. En el sitio de origen se añadía una línea de encabezado al mensaje indicando el nombre y la dirección del sistema de origen. Después de eso, cada sistema por el que viajaba el mensaje se añadía a un encabezado PATH que iba creciendo, así como a un encabezado SEENBY. SEENBY impedía que el mensaje diera vueltas por la red en caso de que la información de enrutamiento estuviera mal configurada. [10]
Echomail no fue el único sistema que utilizó la función de archivos adjuntos de Netmail para implementar capacidades de almacenamiento y reenvío. También se utilizaron conceptos similares en los juegos en línea y otros sistemas.
La evolución hacia el sistema de direccionamiento de red/nodo también resultó útil para reducir los costes de comunicación entre continentes, donde también podían entrar en juego las diferencias horarias en ambos extremos de la conexión. Por ejemplo, el mejor momento para reenviar correo en los EE. UU. era por la noche, pero ese podría no ser el mejor momento para que los hosts europeos intercambiaran. Los esfuerzos por introducir un nivel continental en el sistema de direccionamiento comenzaron en 1986. [10]
Al mismo tiempo, se observó que algunos usuarios avanzados estaban interesados en utilizar los protocolos de FidoNet como una forma de entregar grandes cantidades de correo electrónico a sus máquinas locales, donde se podía leer sin conexión. Estos usuarios no querían que sus sistemas aparecieran en la lista de nodos: no tenían (necesariamente) un sistema de tablón de anuncios y no eran accesibles al público. [10] Era deseable contar con un mecanismo que permitiera la entrega de correo electrónico a estos sistemas sin la sobrecarga que supone el mantenimiento de la lista de nodos.
En octubre de 1986 se lanzó el último cambio importante en la red FidoNet, agregando zonas y puntos . Las zonas representaban áreas geográficas importantes que se correspondían aproximadamente con los continentes. Había seis zonas en total: América del Norte, América del Sur, Europa, Oceanía, Asia y África. Los puntos representaban nodos no públicos, que se creaban de forma privada en un sistema BBS host. El correo de puntos se enviaba a un host seleccionado como si estuviera dirigido a un usuario en esa máquina, pero luego se volvía a empaquetar en un paquete para que el punto lo recogiera a pedido. El formato de direccionamiento completo ahora era zone:net/node.point, por lo que un ejemplo real podría ser Bob Smith@1:250/250.10. [10] Los puntos se usaron ampliamente solo por un corto tiempo, la introducción de sistemas de lectura fuera de línea llenó esta función con sistemas que eran mucho más fáciles de usar. Los puntos siguen utilizándose hasta el día de hoy, pero son menos populares que cuando se introdujeron.
FidoNet admitía archivos adjuntos incluso desde los primeros estándares. Los archivos adjuntos seguían el enrutamiento normal del correo a través de múltiples sistemas y podían respaldar las transferencias a lo largo de la línea a medida que se copiaban los archivos. Además, los usuarios podían enviar archivos a otros usuarios y acumular cargos de larga distancia en un sistema host. Por estas razones, las transferencias de archivos normalmente estaban desactivadas para la mayoría de los usuarios y solo estaban disponibles para los operadores del sistema y los escáneres.
Se ofreció una solución en forma de solicitudes de archivos . Esto invirtió el flujo de información, en lugar de ser impulsado por los sistemas de envío, estos eran impulsados por el sistema de llamada. Esto significaba que era el receptor, el usuario que intentaba obtener el archivo, el que pagaba por la conexión. Además, las solicitudes se enrutaban directamente utilizando conexiones punto a punto únicas en lugar del enrutamiento tradicional, por lo que no causaban que el archivo se copiara varias veces. Dos de estos estándares se volvieron comunes, "WaZOO" y "Bark", que tuvieron un soporte variable entre los diferentes proveedores de correo. Ambos funcionaban de manera similar, con el proveedor de correo llamando al sistema remoto y enviando un nuevo paquete de protocolo de enlace para solicitar los archivos. [16] [17]
Aunque FidoNet era, con diferencia, la red basada en BBS más conocida, no era ni mucho menos la única. A partir de 1988, los sistemas PCBoard pudieron alojar una funcionalidad similar conocida como RelayNet , mientras que otras redes populares incluían RBBSNet del mundo Commodore 64 y AlterNet . Más tarde en la evolución del sistema FidoNet, hubo una propuesta para permitir que el correo (pero no los mensajes del foro) de estos sistemas pasaran a la estructura FidoNet. [18] Esto no se adoptó, y el rápido ascenso de Internet lo hizo superfluo, ya que estas redes añadieron rápidamente el intercambio de Internet, que actuó como una lengua franca .
.svg/1280px-Fidonodes_(en).svg.png)
FidoNet comenzó en 1984 y a finales de ese año ya contaba con 100 nodos. El crecimiento constante continuó durante la década de 1980, pero una combinación de factores condujo a un rápido crecimiento después de 1988. Entre ellos se encontraban módems más rápidos y menos costosos y una rápida disminución de los costos de los discos duros y los sistemas informáticos en general. En abril de 1993, la lista de nodos de FidoNet contenía más de 20.000 sistemas. En ese momento se estimó que cada nodo tenía, en promedio, unos 200 usuarios activos. De estos 4 millones de usuarios en total, 2 millones usaban comúnmente echomail, los foros públicos compartidos, mientras que unos 200.000 usaban el sistema de correo electrónico privado. [10] En su apogeo, FidoNet contaba con aproximadamente 39.000 sistemas. [5] [N 3]
Durante toda su existencia, FidoNet estuvo plagada de problemas de gestión y luchas internas. Gran parte de esto se puede atribuir al hecho de que la distribución por Internet costaba dinero real y el tráfico crecía más rápidamente que las disminuciones causadas por la mejora de la velocidad de los módems y la tendencia a la baja de las tarifas de larga distancia. A medida que aumentaban, se probaron varios métodos para recuperar los costos, todos los cuales causaron fricciones en los grupos. Los problemas eran tan graves que Jennings llegó a referirse al sistema como "la lucha por la red". [19]
A medida que los módems alcanzaban velocidades de 28,8 kbit/s, la conexión a Internet por dial-up se hizo cada vez más común. En 1995, el mercado de los tablones de anuncios se tambaleaba, ya que los usuarios habían abandonado los sistemas BBS locales en favor de una suscripción a un proveedor de Internet local, que permitía el acceso a servicios de Internet de todo el mundo, como HTTP, correo de Internet, etc., por el mismo coste que acceder a un sistema BBS local. Muchos operadores de sistemas BBS se convirtieron en proveedores de servicios de Internet. Sus pasarelas de Internet también hicieron que la implementación de FidoNet fuera menos costosa, porque las transferencias de Internet también podían realizarse a través de Internet, con un coste marginal mínimo o nulo. Pero esto diluyó gravemente todo el propósito del modelo de almacenamiento y reenvío, que se había creado específicamente para abordar un problema de larga distancia que ya no existía.
La lista de nodos de FidoNet comenzó a disminuir, especialmente en áreas con una amplia disponibilidad de conexiones a Internet. Esta tendencia a la baja continúa, pero se ha estabilizado en aproximadamente 2500 nodos. [N 4] FidoNet sigue siendo popular en áreas donde el acceso a Internet es difícil de conseguir o costoso.
Alrededor de 2014, un movimiento retro condujo a un aumento lento de los nodos y BBS conectados a Internet. Telnet, rlogin y SSH se utilizan entre sistemas. Esto significa que el usuario puede comunicarse por telnet con cualquier BBS del mundo por el mismo precio que con los de al lado. Además, se han añadido Usenet y el correo de Internet, junto con nombres de archivo largos a muchas versiones más nuevas del software de BBS, algunas de las cuales son freeware , lo que ha dado lugar a un aumento de su uso. Las listas de nodels ya no están disminuyendo en todos los casos.
FidoNet se rige por una estructura jerárquica de acuerdo con la política de FidoNet, con coordinadores designados en cada nivel para gestionar la administración de los nodos de FidoNet y resolver disputas entre los miembros. [20] Las reglas de conducta se resumen en estos dos principios deliberadamente vagos:
Los coordinadores de red son responsables de gestionar los nodos individuales dentro de su área, normalmente una ciudad o un área de tamaño similar. Los coordinadores regionales son responsables de gestionar la administración de los coordinadores de red dentro de su región, normalmente del tamaño de un estado o un país pequeño. Los coordinadores de zona son responsables de gestionar la administración de todas las regiones dentro de su zona. El mundo está dividido en seis zonas, cuyos coordinadores eligen a uno de ellos para que sea el Coordinador Internacional de FidoNet.
FidoNet fue diseñado históricamente para utilizar acceso telefónico basado en módem entre sistemas de tablones de anuncios, y gran parte de su política y estructura reflejaban esto.
El sistema FidoNet se refería oficialmente sólo a la transferencia de Netmail (los mensajes privados individuales entre personas que utilizan tablones de anuncios), incluidos los protocolos y estándares con los que respaldarlo. Un mensaje de Netmail contendría el nombre de la persona que lo enviaba, el nombre del destinatario previsto y las respectivas direcciones FidoNet de cada uno. El sistema FidoNet era responsable de enrutar el mensaje de un sistema al otro (detalles a continuación), y el software del tablón de anuncios en cada extremo era responsable de garantizar que sólo el destinatario previsto pudiera leerlo. Debido a la naturaleza amateur de la red, cualquier privacidad entre el remitente y el destinatario era sólo el resultado de la cortesía de los propietarios de los sistemas FidoNet involucrados en la transferencia del correo. Sin embargo, era común que los operadores del sistema se reservaran el derecho de revisar el contenido del correo que pasaba por su sistema.
Netmail permitía adjuntar un único archivo a cada mensaje. Esto dio lugar a una serie de protocolos piggyback que añadieron funciones adicionales a FidoNet mediante el envío de información de un lado a otro como archivos adjuntos. Entre ellas se incluían la distribución automática de archivos y la transmisión de datos para juegos entre BBS.
El protocolo más utilizado de estos protocolos de piggyback era Echomail , un sistema de debates públicos similar a los grupos de noticias de Usenet . Echomail contaba con el apoyo de una variedad de software que recogía los mensajes nuevos de los foros públicos de las BBS locales (el escáner ), los comprimía mediante ARC o ZIP , adjuntaba el archivo resultante a un mensaje de Netmail y enviaba ese mensaje a un sistema seleccionado. Al recibir un mensaje de este tipo, identificado porque estaba dirigido a un usuario en particular , se utilizaba el proceso inverso para extraer los mensajes y un analizador los volvía a colocar en los foros del nuevo sistema.
Echomail era tan popular que para muchos usuarios, Echomail era la FidoNet. El correo electrónico privado entre personas era relativamente poco común.
FidoNet está organizada políticamente en una estructura de árbol, en la que las distintas partes del árbol eligen a sus respectivos coordinadores. La jerarquía de FidoNet consta de zonas , regiones , redes , nodos y puntos desglosados más o menos geográficamente.
El nivel más alto es la zona, que en gran medida se basa en el continente:
Cada zona se divide en regiones, que a su vez se dividen en redes, que constan de nodos individuales. Las zonas 7 a 4095 se utilizan para otras redes ; agrupaciones de nodos que utilizan software compatible con Fido para transmitir sus propias áreas de mensajes independientes sin estar controladas de ninguna manera por la estructura política de FidoNet. El uso de números de zona no utilizados garantizaría que cada red tuviera un conjunto único de direcciones, lo que evitaría posibles conflictos de enrutamiento y ambigüedades para los sistemas que pertenecieran a más de una red.
Las direcciones de FidoNet constan explícitamente de un número de zona , un número de red (o número de región) y un número de nodo . Se escriben en la forma Zone:Network/Node. [23] La estructura de FidoNet también permite la designación semántica de la región, el host y el estado del concentrador para nodos particulares, pero este estado no se indica directamente mediante la dirección principal.
Por ejemplo, considere un nodo ubicado en Tulsa, Oklahoma , Estados Unidos , con un número de nodo asignado 918, ubicado en la Zona 1 (Norteamérica), Región 19 y Red 170. La dirección completa de FidoNet para este sistema sería 1:170/918. La región se utilizó para fines administrativos y solo era parte de la dirección si el nodo figuraba directamente debajo del Coordinador regional, en lugar de una de las redes que se usaban para dividir aún más la región.
La política de FidoNet exige que cada sistema de FidoNet mantenga una lista de nodos de todos los demás sistemas miembros. La información sobre cada nodo incluye el nombre del sistema o BBS, el nombre del operador del nodo, la ubicación geográfica, el número de teléfono y las capacidades del software. La lista de nodos se actualiza semanalmente para evitar llamadas no deseadas a nodos que se han apagado y cuyos números de teléfono posiblemente hayan sido reasignados para uso de voz por la compañía telefónica respectiva.
Para realizar actualizaciones periódicas, los coordinadores de cada red mantienen la lista de sistemas en sus áreas locales. Las listas se envían al Coordinador Internacional a través de sistemas automatizados de forma regular. El Coordinador Internacional luego compila una nueva lista de nodos y genera la lista de cambios (nodediff) que se distribuirá para que los operadores de nodos apliquen a su lista de nodos existente.
En una situación teórica, un nodo normalmente reenviaría mensajes a un concentrador . El concentrador, que actúa como punto de distribución del correo, podría entonces enviar el mensaje al Coordinador de red. Desde allí, podría enviarse a través de un Coordinador regional o a algún otro sistema configurado específicamente para esa función. El correo a otras zonas podría enviarse a través de una Puerta de zona.
Por ejemplo, un mensaje de FidoNet podría seguir la ruta:
Originalmente no había una relación específica entre los números de red y las regiones en las que se encuentran. En algunas áreas de FidoNet, especialmente en la Zona 2, la relación entre el número de región y el número de red está entrelazada. Por ejemplo, 2:201/329 está en la Red 201, que está en la Región 20, mientras que 2:2410/330 está en la Red 2410, que está en la Región 24. La Zona 2 también relaciona el número de nodo con el número de concentrador si la red es lo suficientemente grande como para contener concentradores. Este efecto se puede ver en la lista de nodos al observar la estructura de la Red 2410, donde el nodo 2:2410/330 aparece en la lista del concentrador 300. Este no es el caso en otras zonas.
En la Zona 1, las cosas son muy diferentes. La Zona 1 fue el punto de partida y cuando se formaron las Zonas y Regiones, las redes existentes se dividieron regionalmente sin una fórmula establecida. La única consideración que se tuvo fue dónde se ubicaban geográficamente con respecto al contorno mapeado de la región. A medida que se fueron agregando números de redes, se utilizó la siguiente fórmula.
Número de región × 20
Luego, cuando algunas regiones comenzaron a quedarse sin números de red, también se utilizó lo siguiente.
Número de región × 200
La Región 19, por ejemplo, contiene las redes 380-399 y 3800-3999, además de las que había en la Región 19 cuando se formó.
Parte del objetivo detrás de la formación de redes locales fue implementar planes de reducción de costos mediante los cuales todos los mensajes se enviarían a uno o más centros o hosts en forma comprimida ( ARC era nominalmente el estándar, pero PKZIP tiene soporte universal); luego se podría hacer una llamada fuera de horas pico para intercambiar archivos completos llenos de mensajes con un enlace ascendente fuera de la ciudad para una mayor redistribución.
En la práctica, la estructura de FidoNet permite que cualquier nodo se conecte directamente con cualquier otro, y los operadores de nodos a veces formaban sus propios acuerdos de llamadas de larga distancia según las necesidades, lo que permitía un equilibrio entre el ahorro de costos colectivos y la entrega oportuna. Por ejemplo, si un operador de nodo en una red se ofrecía a hacer llamadas de larga distancia regulares a un sistema particular en otro lugar, otros operadores podían acordar reenviar todo su correo destinado al sistema remoto, y a los que estaban cerca de él, al voluntario local. Los operadores dentro de redes individuales a veces tenían acuerdos de costos compartidos, pero también era común que la gente se ofreciera voluntariamente a pagar llamadas de larga distancia regulares, ya sea por generosidad o para construir su estatus en la comunidad.
Este sistema ad hoc era particularmente popular en las redes que se construyeron sobre FidoNet. Echomail, por ejemplo, a menudo implicaba transferencias de archivos relativamente grandes debido a su popularidad. Si los distribuidores oficiales de FidoNet se negaban a transferir Echomail debido a los cargos adicionales, otros operadores de nodos se ofrecían como voluntarios. En tales casos, los mensajes de Echomail se enrutaban a los sistemas de los voluntarios.
El sistema FidoNet se adaptó mejor a un entorno en el que el servicio telefónico local era económico y las llamadas de larga distancia (o la transferencia de datos entre ciudades a través de redes de conmutación de paquetes ) costosas. Por lo tanto, tuvo un desempeño algo pobre en Japón , donde incluso las líneas locales son caras, o en Francia , donde los peajes en las llamadas locales y la competencia con Minitel u otras redes de datos limitaron su crecimiento.
A medida que el número de mensajes en Echomail fue creciendo con el tiempo, se hizo muy difícil para los usuarios mantenerse al día con el volumen mientras estaban conectados a su BBS local. Se introdujeron puntos para solucionar este problema, permitiendo a los usuarios con conocimientos técnicos recibir el Echomail (y Netmail) ya comprimido y procesado por lotes y leerlo localmente en sus propias máquinas. [24]
Para ello, se amplió el esquema de direcciones de FidoNet con la incorporación de un segmento de dirección final, el número de punto. Por ejemplo, a un usuario del sistema de ejemplo anterior se le podría asignar el número de punto 10 y, por lo tanto, se le podría enviar un correo a la dirección 1:170/918.10.
En el uso real, los puntos son bastante difíciles de configurar. El software de FidoNet generalmente consistía en una serie de pequeños programas de utilidad ejecutados mediante scripts editados manualmente que requerían cierto nivel de habilidad técnica. Para leer y editar el correo se necesitaba un programa de "editor de sistema" o un programa BBS que se ejecutara localmente.
En América del Norte (Zona 1), donde las llamadas locales son generalmente gratuitas, los beneficios del sistema se vieron contrarrestados por su complejidad. Los puntos se utilizaron sólo brevemente, e incluso entonces sólo en un grado limitado. Los programas dedicados a la lectura de correo sin conexión, como Blue Wave , Squiggy y Silver Xpress (OPX), se introdujeron a mediados de los años 90 y rápidamente dejaron obsoleto el sistema de puntos. Muchos de estos paquetes admitían el estándar de correo sin conexión QWK .
En otras partes del mundo, especialmente en Europa, esto era diferente. En Europa, incluso las llamadas locales suelen tener un coste, por lo que había un fuerte incentivo para mantener la duración de las llamadas lo más corta posible. El software Point utiliza una compresión estándar (ZIP, ARJ, etc.) y, por lo tanto, reduce las llamadas a unos pocos minutos al día como máximo. A diferencia de América del Norte, el sistema Point tuvo una adopción rápida y bastante generalizada en Europa.
Muchas regiones distribuyen una lista de puntos en paralelo con la lista de nodos. Los Guardianes de listas de puntos de la red y de la región mantienen los segmentos de la lista de puntos y el Guardian de listas de puntos de la zona los reúne en la lista de puntos de la zona. En el apogeo de FidoNet había más de 120.000 puntos listados en la lista de puntos de la zona 2. La inclusión de puntos en la lista es voluntaria y no todos los puntos están listados, por lo que nadie sabe cuántos puntos había realmente. En junio de 2006, todavía había unos 50.000 puntos listados. La mayoría de ellos están en Rusia y Ucrania.
FidoNet contenía varias especificaciones técnicas para la compatibilidad entre sistemas. La más básica de todas es la FTS-0001 [25] , con la que todos los sistemas FidoNet deben cumplir como requisito mínimo. La FTS-0001 definía:
Otras especificaciones que se usaban comúnmente incluían echomail , diferentes protocolos de transferencia y métodos de enlace ( por ejemplo: Yoohoo/Yoohoo2u2, EMSI ), compresión de archivos, formato de lista de nodos, transferencia a través de conexiones confiables como Internet ( Binkp ) y otros aspectos.
Dado que los tablones de anuncios informáticos históricamente utilizaban las mismas líneas telefónicas para transferir correo que las que se utilizaban para los usuarios humanos que accedían mediante acceso telefónico al BBS, la política de FidoNet dicta que al menos una línea designada de cada nodo de FidoNet debe estar disponible para aceptar correo de otros nodos de FidoNet durante una hora particular de cada día. [26]
La hora de correo por zona , como se la denominó, varía según la ubicación geográfica del nodo y se designó para que se produjera durante las primeras horas de la mañana. La hora exacta varía según la zona horaria y cualquier nodo con una sola línea telefónica debe rechazar las llamadas de personas. En la práctica, particularmente en épocas posteriores, la mayoría de los sistemas FidoNet tienden a aceptar correo en cualquier momento del día cuando la línea telefónica no está ocupada, generalmente durante la noche.
La mayoría de las implementaciones de FidoNet se diseñaron de manera modular. Una implementación típica implicaría varias aplicaciones que se comunicarían a través de archivos y directorios compartidos y se intercambiarían entre sí mediante scripts o archivos por lotes cuidadosamente diseñados . Sin embargo, existe un software monolítico que abarca todas las funciones requeridas en un solo paquete, como D'Bridge. Este software eliminó la necesidad de archivos por lotes personalizados y está estrechamente integrado en la operación. La preferencia de implementación era la del operador y existían pros y contras de ejecutarse de cualquier manera.
Se podría decir que el software más importante de un sistema Fido basado en DOS era el controlador FOSSIL , que era un pequeño controlador de dispositivo que proporcionaba una forma estándar para que el software Fido se comunicara con el módem. [27] Este controlador debía cargarse antes de que cualquier software Fido pudiera funcionar. Un controlador FOSSIL eficiente significaba conexiones más rápidas y confiables.
El software de correo era responsable de transferir archivos y mensajes entre sistemas, así como de pasar el control a otras aplicaciones, como el software BBS, en los momentos apropiados. El correo respondía inicialmente al teléfono y, si era necesario, se ocupaba del correo entrante a través de los protocolos de transferencia FidoNet. Si el correo respondía al teléfono y se detectaba una llamada humana en lugar de otro software de correo, el correo salía y pasaba el control al software BBS, que luego se inicializaba para la interacción con el usuario. Cuando el correo saliente estaba esperando en el sistema local, el software de correo intentaba enviarlo de vez en cuando marcando y conectándose a otros sistemas que aceptarían y enrutarían el correo. Debido a los costos de las llamadas de peaje, que a menudo variaban entre las horas punta y las horas no punta, el software de correo generalmente permitía a su operador configurar los horarios óptimos en los que intentar enviar correo a otros sistemas.
El software BBS se utilizó para interactuar con los usuarios que llamaban al sistema. El software BBS permitía a los usuarios que accedían por teléfono utilizar las bases de mensajes del sistema y escribir correos a otros usuarios, localmente o en otros BBS. El correo dirigido a otros BBS se enrutaba y enviaba posteriormente por el remitente, normalmente después de que el usuario hubiera terminado de utilizar el sistema. Muchos BBS también permitían a los usuarios intercambiar archivos, jugar e interactuar con otros usuarios de diversas formas (por ejemplo, chat de nodo a nodo).
Normalmente, se invocaría una aplicación de escaneo/descarga , como FastEcho , FMail, TosScan y Squish, cuando un usuario de BBS hubiera ingresado un nuevo mensaje de FidoNet que necesitaba ser enviado, o cuando un remitente de correo hubiera recibido correo nuevo para ser importado a las bases de mensajes locales. Esta aplicación sería responsable de manejar el empaquetado del correo entrante y saliente, moviéndolo entre las bases de mensajes del sistema local y los directorios de entrada y salida del remitente. La aplicación de escaneo/descarga generalmente sería responsable de la información básica de enrutamiento, determinando a qué sistemas reenviar el correo.
En épocas posteriores, también se desarrollaron lectores o editores de mensajes que eran independientes del software BBS. A menudo, el operador del sistema de un BBS en particular utilizaba un lector de mensajes dedicado, en lugar del propio software BBS, para leer y escribir mensajes de FidoNet y relacionados. Uno de los editores más populares en 2008 fue GoldED+ . En algunos casos, los nodos FidoNet, o más a menudo los puntos FidoNet, no tenían un tablón de anuncios público adjunto y existían solo para la transferencia de correo en beneficio del operador del nodo. La mayoría de los nodos en 2009 no tenían acceso a BBS, sino solo puntos, si acaso.
El software original de Fido BBS y otros programas compatibles con FidoNet de la década de 1980 ya no funcionan en los sistemas modernos. Esto se debe a varias razones, incluidos los problemas relacionados con el error Y2K . En algunos casos, los autores originales abandonaron la comunidad de BBS o shareware , y el software, gran parte del cual era de código cerrado , ya no recibe soporte.
Varios programas de correo FidoNet basados en DOS, como FrontDoor , Intermail, MainDoor y D'Bridge de principios de los años 90, todavía se pueden ejecutar hoy en día en Windows sin módem, utilizando el controlador gratuito NetFoss Telnet FOSSIL y utilizando un módem virtual como NetSerial. Esto permite que el programa de correo marque una dirección IP o un nombre de host a través de Telnet, en lugar de marcar un número de teléfono POTS real . Existen soluciones similares para Linux, como MODEMU (emulador de módem), que tiene un éxito limitado cuando se combina con DOSEMU (emulador de DOS). Los lanzadores de correo como FastEcho y FMail todavía se utilizan hoy en día tanto en Windows como en Linux/DOSEMU.
Existen varios programas de correo FidoNet basados en Windows disponibles actualmente con código fuente, incluidos Argus, Radius y Taurus. MainDoor es otro programa de correo FidoNet basado en Windows, que también se puede ejecutar utilizando un módem o directamente sobre TCP/IP. Dos programas de correo FidoNet gratuitos y de código abierto populares para sistemas tipo Unix son binkd (multiplataforma, solo IP, utiliza el protocolo binkp ) y qico (admite comunicación por módem así como el protocolo IP de ifcico y binkp).
En cuanto al hardware , los sistemas Fido solían ser máquinas bien equipadas para su época, con CPU rápidas, módems de alta velocidad y UART 16550 , que en ese momento eran una mejora. Como un sistema Fidonet era normalmente un BBS, necesitaba procesar rápidamente cualquier nuevo evento de correo antes de volver a su estado de "espera de llamada". Además, el propio BBS solía necesitar mucho espacio de almacenamiento. Por último, un sistema FidoNet solía tener al menos una línea telefónica dedicada. En consecuencia, operar un sistema Fidonet a menudo requería una inversión financiera significativa, un costo que generalmente asumía el propietario del sistema.
Si bien el uso de FidoNet ha disminuido drásticamente en comparación con su uso hasta mediados de la década de 1990, aún se utiliza en muchos países y especialmente en Rusia y las antiguas repúblicas de la URSS. [ cita requerida ] Algunos BBS, incluidos aquellos que ahora están disponibles para usuarios con conexiones a Internet a través de telnet , también conservan sus feeds de netmail y echomail de FidoNet.
Algunas de las conferencias de correo electrónico de FidoNet están disponibles a través de puertas de enlace con la jerarquía de noticias de Usenet que utilizan software como UFGate. También hay puertas de correo para intercambiar mensajes entre Internet y FidoNet. El abuso generalizado de la red y el correo basura en Internet han provocado que algunas puertas de enlace (como la antigua puerta de enlace IEEE fidonet.org 1:1/31) se vuelvan inutilizables o dejen de funcionar por completo.
FidoNews es el boletín de noticias de la comunidad FidoNet. Apodado cariñosamente The Snooze , se publica semanalmente. Se publicó por primera vez en 1984. A lo largo de su historia, ha sido publicado por varias personas y entidades, incluida la efímera Asociación Internacional FidoNet. Desde enero de 2002, ha sido publicado por Björn Felten, Suecia.
he eliminado la última entrada de la Zona 6 al momento de escribir este artículo. Todos los miembros restantes han sido transferidos a la Zona 3 como lo determinaron previamente los miembros de la Zona 6 en general.
