Clasificación de BBS y su utilidad

---

Ponencia realizada por EA3CIW en SYSEA'94.
Publicado en: DIGICLUB.

---

En distintos escritos de SYSEA, a lo largo de estos años, se habla reiteradamente de "BBS principales", "BBS secundarias", "BBS de apoyo", etc., pero no se llega a concretar exactamente su definición o utilidad característica. El presente documento pretende justificar la existencia de esta clasificación y el rol de cada una dentro de la Red.

---

La Red SYSEA: un conjunto de subredes

De hecho, la Red SYSEA está dividida en subredes, con cierto grado de autonomía, pero interconectadas entre sí. Podríamos considerar a cada Zona SYSEA como una subred y a SYSEA como el conjunto de estas subredes.

Entonces el problema del forwarding se reduce a intercambiar mensajes entre subredes, con la certeza de que, dentro de la subred, se distribuirá al elemento (BBS) correspondiente.

Puestas así las cosas, el problema de enviar mensajes a 60 BBS se simplifica a enviarlo solamente a 15 zonas. De la coherencia de cada zona dependerá que esta simplificación sea cierta.

Entonces, ¿porqué no buscar una BBS en cada zona a la que mandar todo el correo y que se encargue ella de redistribuirlo? ¿Qué características debe tener esta BBS? ¿Cómo preveer las alternativas en caso de fallo?

BBS principal: su misión dentro de la Red

No se trata de establecer un escalafón, sino de que los Sysops de la zona consensuen cual es la BBS más adecuada, por sus medios técnicos, enlaces alternativos (port telefónico, HF, etc.), capacidad de proceso o de disco para ejecutar los Servers que se acuerden, número de Sysops, preparación de los mismos. etc., para actuar como BBS principal.

Un criterio simple pero efectivo puede ser: escoger la BBS de la cual el Coordinador de Zona es Sysop.

Un ejemplo de misión a cumplir por parte de las BBS principales es la distribución de mensajes personales entre Sysops de la Red SYSEA de una forma óptima, es decir, que no tengan que salir 60 mensajes personales de un solo punto de la red y cruzar un enlace ya de por si saturado (caso de HF) o con un elevado coste (caso del teléfono). Ver apartados posteriores sobre Servers que deberían tener las BBS principales.

BBS secundaria: igual de importante

Excepto por los pequeños detalles organizativos y de enlace que se requieren para que una BBS sea principal, las BBS secundarias también deben estar operativas 24 horas para los usuarios, principal razón de ser de toda la Red SYSEA.

BBS de apoyo: imprescindibles

Quizás si la red de nodos hubiera evolucionado más, tendríamos una red con BBS de asociaciones en su local social y nodos en las montañas. Esta no es la situación actual y gracias a la colaboración desinteresada de muchos particulares se consigue transferir la mensajería a toda la Red.

El denominador común de las llamadas BBS de apoyo es su funcionamiento a tiempo parcial y que no permiten usuarios, siendo su misión principal la del forwarding.

Lista de distribución SYSEA

Desarrollando el ejemplo anterior, pongamos por caso la convocatoria de la reunión anual SYSEA. Además de los boletines que se generen, enviar información semi-personalizada a cada Sysop supone unos 60 mensajes, más de la mitad de los cuales circulan por HF o por teléfono en algún tramo de la Red.

Si en vez de enviar 60 mensajes, enviamos uno a cada zona (total 15) para que se redistribuya una vez allí, el tráfico se reduce ostensiblemente.

Para implementar esta lista de distribución con todos los Sysops necesitamos el programa de copias MULTI.EXE o similar, que configuraremos al final del INIT.SRV de cada BBS principal tal que así:

SYSEA   MULTI.EXE  Lista de distribucion SYSEA
SYSEA3  MULTI.EXE  Lista de distribucion SYSEA3

Donde SYSEA3 se sustituirá por el nombre de la zona de la cual esta BBS es principal.

El programa MULTI.EXE se colocará en \FBB\BIN y en \FBB crearemos dos ficheros: SYSEA.DAT y SYSEA3.DAT.

Un posible contenido de SYSEA.DAT podría ser:

SYSE1G @ EA1RCA
SYSE1L @ EA1RKS
SYSE2A @ EA2RCG
SYSE2E @ EA2RCG
SYSEA3 @ EA3CIW
SYSE4C @ EB4BCS
SYSE4E @ EA4PL
SYSE4M @ EB4BVH
SYSE5N @ EA5VDR
SYSE5S @ EA5VDR
SYSEA6 @ EA6RCD
SYSE7E @ EA7CNM
SYSE7O @ EA7RCS
SYSEA8 @ EA8AML
SYSEA9 @ EA9MH

Donde a las zonas con distintivo de 7 caracteres se les ha suprimido la A para que queden con 6, que es la longitud máxima del campo de indicativo en AX.25.

En este ejemplo se han tomado las BBS sede de los Coordinadores. En las zonas sin BBS SYSEA se les ha asignado la más cercana.

Por otra parte, el fichero SYSEA3.DAT contendría lo siguiente:

EA3GGT
EA3CWZ
EA3BFE
EA3BLN
EA3CIW

que son los indicativos de los Sysops de las BBS de la Zona. En caso de no usar WP se puede añadir la @BBS donde reciben el correo a continuación del indicativo de Sysop.

De esta manera, no sólo evitamos QRM, sino que accedemos a una lista de rigurosa actualidad, porque cada Coordinador se encargará de actualizar en su BBS principal con las variaciones o incorporaciones habidas. Para mandar mensaje a todos los Sysops de la zona SYSEA3 no es necesario conocer quienes son, basta enviar SP SYSEA3 @ EA3CIW.EAB.ESP.EU. El programa MULTI.EXE genera un mensaje de retorno con los indicativos a los que se les ha mandado una copia. Si no es imprescindible, no abusar de la prestación /ACK.

Redistribución de boletines: REDIST

Un Server muy interesante, desde mi punto de vista, es el REDIST. Dicho server permite, por ejemplo, que un colega alemán pueda mandar un mensaje para que se distribuya por toda España (@EA) sin necesidad de que sea @EU o @WW. Basta con que mande un mensaje así: SP NATION @ EA3CIW.

Al llegar a la BBS EA3CIW el server REDIST entra en acción y genera un boletín de ámbito @EA a partir del mensaje recibido como SP NATION. Es el Sysop local quien configura que el ámbito nacional sea @EA.

Asimismo también existen los ámbitos: regionales (REGION), locales (LOCAL) y para la BBS local (LOCBBS).

Siguiendo con el ejemplo de configuración de la BBS EA3CIW, para el ámbito REGION se configura @EA3, para el LOCAL la província @B y para LOCBBS la BBS EA3CWZ que está en Barcelona capital.

Así aparece en el fichero INIT.SRV, en el cual se ha tenido en cuenta que colegas extranjeros puedan pedir con REQCFG saber si esta activo este server:

LOCBBS  REDIST.EXE     Bulletins to Barcelona capital BBS
LOCAL   REDIST.EXE     Barcelona province bulletins
REGION  REDIST.EXE     Catalonia bulletins
NATION  REDIST.EXE     Whole Spain bulletins

La publicación, en las BBS de la red, de que ámbitos están activos en toda España, pueden ser utiles para que en un momento dado algún EA7 desee poner un boletín a la zona @MADRID para buscar un determinado componente o colega, sin necesidad de distribuirlo @EA, puesto que su interés se centra en Madrid.

Esta puede ser otra de las utilidades de un BBS principal.