Resumen

  • En RFC 2024, una fila del directorio indicaba dónde creía un nodo DLSw que podía alcanzar una dirección MAC o un nombre NetBIOS; no afirmaba que existiera un circuito activo.
  • El transporte, el circuito, el ritmo y los datos de desconexión respondían preguntas distintas y debían conservarse como una cadena de pruebas.

Una consola puede convertir varias condiciones en una sola luz verde. RFC 2024 hizo lo contrario. Dio al gestor un directorio para localizar recursos, una tabla operativa para las conexiones entre pares DLSw, otra para los circuitos de las estaciones finales y objetos específicos para ritmo, estadísticas y fallos. La arquitectura obligaba a preguntar qué mecanismo había producido cada dato.

La ubicación era una creencia registrada

Las tablas de direcciones MAC y nombres NetBIOS vinculaban cada recurso con un puntero de ubicación. Este podía señalar una interfaz local, una conexión configurada, una conexión operativa, una referencia nula o una tabla propia de la implementación. El estado —desconocido, alcanzable o no alcanzable— expresaba lo que DLSw creía en ese momento sobre el acceso por esa ubicación.

Los ejemplos estáticos muestran la cautela. Una entrada podía empezar como desconocida. Varios pares remotos podían anunciar el mismo recurso. El orden de los candidatos no estaba garantizado y, con igual especificidad, el conflicto entre información estática y dinámica podía resolverse de modo distinto según el producto. Tras un fallo, una entrada no alcanzable podía servir para no repetir enseguida la búsqueda.

Por tanto, el directorio reducía las opciones. No demostraba que el par elegido estuviera conectado, que la creación del circuito hubiera empezado ni que la estación contestara.

Una conexión de transporte tenía su propio tiempo

La tabla operativa distinguía conexión en curso, intercambio inicial de capacidades, conectado, reposo, desconexión y desconectado. Conectado quería decir que los pares habían determinado sus capacidades y estaban listos para mensajes de creación de circuitos. No era un resultado de extremo a extremo.

La relación con la configuración tampoco era eterna. dlswTConnOperConfigIndex apuntaba a la fila que gobernaba la conexión, pero pasaba a cero si esa fila se borraba. Si la configuración cambiaba después del establecimiento, la conexión podía seguir reflejando condiciones negociadas antes. Por eso el instante de conexión y el de última modificación formaban parte de la lectura.

Además, un agente podía conservar una fila después de desconectar para guardar estadísticas y el motivo del fallo, sin plazo obligatorio. Las capacidades recibidas del par podían seguir visibles. Un campo poblado en esa fila histórica no acreditaba disponibilidad presente.

El circuito empezaba después de explorar

RFC 2024 separaba la puesta en marcha en dos fases. Los exploradores localizaban primero la dirección o el nombre; después comenzaba el establecimiento del circuito. Solo entonces aparecía una fila en la tabla de circuitos.

El circuito recorría una secuencia de estados propia. El único estado escribible era disconnectPending; no había una orden de gestión para restablecerlo porque las estaciones finales impulsaban su creación. Los motivos de desconexión y los punteros a las MIB LLC o SDLC subyacentes aportaban indicios. Algunas cifras de tráfico exigían seguir esos punteros. Ninguna fila sustituía toda la investigación causal.

Los créditos de ritmo también tenían un significado preciso: cuántos mensajes SSP acompasados estaba autorizado a enviar un lado antes de parar. Cero también podía significar que el control de ritmo no se usaba. Una ventana concedida no era un recuento de mensajes entregados, sesiones útiles o trabajo terminado.

Las traps hablaban de un cambio observado

Una notificación podía emitirse cuando el transporte o el circuito entraban en conectado. La emisión era configurable y podía desactivarse. Recibirla demostraba que un agente local comunicó una transición y que el aviso llegó; no que el estado perdurara, que el otro par coincidiera o que no hubiese una desconexión posterior. Tampoco el silencio probaba que nada ocurrió.

El momento y motivo de desconexión y el indicador de circuitos activos acotaban el incidente. Este último decía que podía haber usuarios afectados, no cuántos ni con qué pérdida. RFC 2166 añadió después a RFC 1795 motivos HALT generales parecidos a estas categorías. Los pares antiguos podían omitirlos y el detalle del fabricante variar. Era una pista mejor transportada, no una causa definitiva.

La imagen completa podía estar repartida

RFC 2024 advertía que una imagen completa podía requerir consultar varios nodos DLSw. Para reducir duplicación, cierta información se definía como recibida del par. El protocolo tampoco proporcionaba una forma de correlacionar la dirección de transporte gestionada del otro nodo con su dirección de gestión.

Cada fila era así un testimonio local con límites. La separación de Heng Lu entre un registro y la realidad que describe ofrece una lente útil: el registro puede ser exacto sin contener toda la condición operativa. Es una interpretación editorial contemporánea, no una intención atribuida a los autores del RFC.

La respuesta no es desconfiar de las tablas, sino unirlas correctamente. El directorio prueba la creencia de ubicación; el transporte, el estado y tiempo de negociación; el circuito, la trayectoria de las estaciones; las MIB inferiores, el contexto local. Cuando se preservan índices y tiempos, RFC 2024 da una explicación. Cuando todo se resume en verde, da una ilusión.

Fuentes