Comunicaciones binarias síncronas

La comunicación binaria síncrona ( BSC o Bisync ) es un protocolo de enlace semidúplex orientado a caracteres de IBM , anunciado en 1967 tras la introducción del System/360 . Reemplazó el protocolo de transmisión-recepción síncrona (STR) utilizado en los ordenadores de segunda generación. El objetivo era que se pudieran utilizar reglas comunes de gestión de enlaces con tres codificaciones de caracteres diferentes para los mensajes.

La transcodificación de seis bits miraba hacia el pasado, a los sistemas más antiguos; USASCII, con 128 caracteres, y EBCDIC , con 256 caracteres, miraban hacia el futuro. La transcodificación desapareció muy rápidamente, pero los dialectos EBCDIC y USASCII de Bisync continuaron en uso.

En su momento, Bisync fue el protocolo de comunicaciones más utilizado ^{[ 1 ]} y todavía se utiliza de forma limitada en 2013. ^{[ 2 ] [ 3 ]}

Bisync se diferencia de los protocolos que lo sucedieron por la complejidad del encuadre de mensajes. Los protocolos posteriores utilizan un único esquema de encuadre para todos los mensajes que envían. HDLC , el Protocolo de Mensajes de Comunicaciones de Datos Digitales (DDCMP), el Protocolo Punto a Punto (PPP), etc., tienen esquemas de encuadre diferentes, pero solo existe un formato de trama dentro de cada protocolo. Bisync tiene cinco formatos de trama diferentes.

ACK0 y ACK1 (acuse de recibo afirmativo par/impar) se codifican como dos caracteres : DLE '70'x y DLE / para EBCDIC, DLE 0 y DLE 1 para USASCII, DLE - y DLE T para Transcode. WABT (espera antes de transmitir) se codificó como DLE ", DLE  ? o DLE W.

Todos los formatos de trama comienzan con al menos dos bytes SYN . ​​La forma binaria del byte SYN tiene la propiedad de que ninguna rotación del byte es igual al original. Esto permite al receptor encontrar el inicio de una trama buscando el patrón SYN en el flujo de bits recibido. Cuando se encuentra, se ha logrado la sincronización tentativa de bytes. Si el siguiente carácter también es un SYN, se ha logrado la sincronización de caracteres. El receptor entonces busca un carácter que pueda iniciar una trama. Los caracteres fuera de este conjunto se denominan "gráficos iniciales". A veces se utilizan para identificar al remitente de una trama. Los mensajes largos tienen bytes SYN insertados aproximadamente cada segundo para mantener la sincronización. Estos son ignorados por el receptor.

Un carácter normal de fin de bloque (ETB o ETX) va seguido de una suma de comprobación (caracter de comprobación de bloque o BCC). Para USASCII, se trata de una comprobación de redundancia longitudinal (LRC) de un carácter; para Transcode y EBCDIC, la suma de comprobación es una comprobación de redundancia cíclica (CRC) de dos caracteres. Un marco de datos puede contener una suma de comprobación intermedia precedida por un carácter ITB. Esta capacidad de incluir sumas de comprobación intermedias en un marco de datos largo permite una mejora considerable en la probabilidad de detección de errores. Los caracteres USASCII también se transmiten con paridad impar para una comprobación adicional.

Tras un cambio de línea, se requieren caracteres de relleno : NAK, EOT, ENQ, ACK0, ACK1. Si la transmisión finaliza con EOT o ETX, el relleno sigue al BCC. Este relleno puede consistir en bits '1' o bits '0' y '1' alternados. La siguiente transmisión comienza con un carácter de relleno que puede ser cualquiera de los anteriores o un SYN.

Un encabezado opcional que contiene información de control puede preceder a los datos en una trama. El contenido del encabezado no está definido por el protocolo, sino que se define para cada dispositivo específico. Si está presente, el encabezado va precedido por un carácter SOH (inicio de encabezado) y seguido por un STX (inicio de texto). ^{[ 4 ]}

Los datos de texto normalmente siguen al encabezado, comienzan con STX y terminan con ETX (fin de texto) o ETB (fin de bloque de transmisión).

Los marcos de datos normales no permiten la aparición de ciertos caracteres. Estos son los caracteres de fin de bloque: ETB, ETX y ENQ, así como los caracteres ITB y SYN. ​​Por lo tanto, el número de caracteres únicos que se pueden transmitir está limitado a 59 para Transcode, 123 para USASCII o 251 para EBCDIC.

El enmarcado de datos transparente proporciona un alfabeto ilimitado de 64, 128 o 256 caracteres. En el modo transparente, los caracteres de enmarcado de bloques como ETB, ETX y SYN van precedidos por un carácter DLE para indicar su significado de control (el propio carácter DLE se representa mediante la secuencia DLE DLE). Esta técnica se conoció como relleno de caracteres , por analogía con el relleno de bits .

El protocolo de control de enlace es similar a STR. Los diseñadores intentaron protegerlo contra errores de transmisión simples. El protocolo requiere que cada mensaje sea confirmado (ACK0/ACK1) o rechazado (NAK), por lo que la transmisión de paquetes pequeños tiene una alta sobrecarga. El protocolo puede recuperarse de una trama de datos corrupta, una trama de datos perdida y una confirmación perdida.

La recuperación de errores se realiza mediante la retransmisión de la trama dañada. Dado que los paquetes de datos Bisync no tienen numeración secuencial, es posible que una trama se pierda sin que el receptor se dé cuenta. Por lo tanto, se utilizan ACK0 y ACK1 alternados; si el transmisor recibe un ACK incorrecto, puede asumir que se ha perdido un paquete de datos (o un ACK). Un posible fallo es que la corrupción de ACK0 en ACK1 podría provocar la duplicación de una trama.

La protección contra errores para ACK0 y ACK1 es débil. La distancia de Hamming entre los dos mensajes es de solo dos bits.

El protocolo es semidúplex (2 hilos). En este entorno, los paquetes o tramas de transmisión son estrictamente unidireccionales, lo que requiere un "reenvío" incluso para los propósitos más simples, como los acuses de recibo. El reenvío implica

• la inversión de la dirección de transmisión,
• quietud del eco de la línea,
• Resincronizando.

En un entorno de 2 cables, esto provoca un retardo de ida y vuelta notable y reduce el rendimiento.

Algunos conjuntos de datos admiten la operación dúplex completo , y esta (de 4 hilos) puede utilizarse en muchas circunstancias para mejorar el rendimiento al eliminar el tiempo de respuesta, aunque con el coste adicional de la instalación y el soporte de 4 hilos. En el modo dúplex completo típico, los paquetes de datos se transmiten a través de un par de cables, mientras que las confirmaciones se reciben a través del otro.

Gran parte del tráfico bisíncrono es punto a punto . Las líneas punto a punto pueden utilizar la contención para determinar la estación maestra. En este caso, un dispositivo puede transmitir ENQ para pujar por el control. El otro dispositivo puede responder ACK0 para aceptar la puja y prepararse para recibir, o NAK o WABT para rechazarla. En algunos casos, es posible conectar un terminal a varios hosts a través de la red telefónica conmutada.

La comunicación multipunto forma parte del protocolo Bisync inicial. Una estación maestra, normalmente un ordenador, puede sondear secuencialmente terminales conectadas mediante puentes analógicos a la misma línea de comunicación. Esto se logra enviando un mensaje que consiste únicamente en el carácter ENQ, dirigido a cada dispositivo por turno. La estación seleccionada transmite entonces un mensaje a la maestra o responde con EOT para indicar que no tiene datos que transmitir.

El propósito original de Bisync era la comunicación por lotes entre un mainframe System/360 y otro mainframe o un terminal de entrada remota de trabajos (RJE), como el IBM 2780 o el IBM 3780. Los terminales RJE admiten un número limitado de formatos de datos: imágenes de tarjetas perforadas de entrada y salida e imágenes de líneas de impresión. Algunos proveedores de hardware ajenos a IBM, como Mohawk Data Sciences, utilizaron Bisync para otros fines, como la transmisión de cinta a cinta. Un programador puede emular fácilmente un terminal RJE u otro dispositivo.

IBM presentó los terminales de visualización 3270 en 1971. La unidad de control 3271 y la estación de visualización 3275 ofrecían alternativas BSC al controlador local 3272 conectado por canal.

IBM ofreció macros en lenguaje ensamblador para brindar soporte de programación. Durante la era del System/360, estos métodos de acceso fueron inicialmente BTAM (Método Básico de Acceso a Telecomunicaciones) y QTAM (Método de Acceso a Telecomunicaciones en Cola), que posteriormente fue reemplazado por el Método de Acceso a Telecomunicaciones (TCAM). IBM introdujo VTAM (Método Virtual de Acceso a Telecomunicaciones) con el System/370 .

Los sistemas de teleprocesamiento, como el CICS de IBM y el software de terceros, como Remote DUCS (sistema de control de unidades de visualización) y las plataformas Westi, utilizaban el control de línea Bisync para comunicarse con dispositivos remotos.

La red informática académica BITNET , junto con las redes de conexión en otras áreas geográficas, utilizó Bisync para conectar 3000 sistemas informáticos en su momento de mayor actividad.

La red financiera SWIFT utilizaba el protocolo BSC para la comunicación entre el centro regional y el servidor de la institución (banco) a través de una línea arrendada. A mediados de la década de 1990, el protocolo BSC fue reemplazado por la infraestructura X.25 .

Algunos sistemas importantes utilizan el enmarcado de datos Bisync con un protocolo de control de enlace diferente. Houston Automatic Spooling Priority (HASP) utiliza hardware semidúplex Bisync junto con su propio protocolo de control de enlace para proporcionar comunicación dúplex completo de múltiples flujos de datos entre una computadora pequeña y una computadora central que ejecuta HASP. En términos de Bisync, esto es el modo conversacional .

Algunas de las primeras redes X.25 toleraban un esquema de conexión donde los marcos de datos Bisync transparentes encapsulaban paquetes de datos y control HDLC LAPB . A partir de 2012Varios proveedores encapsulan las transmisiones Bisync dentro de flujos de datos TCP/IP.

En la década de 1970, la arquitectura bisincronizada (SNA) comenzó a ser reemplazada por esta, permitiendo la construcción de una red con múltiples hosts y programas mediante telecomunicaciones. X.25 y el Protocolo de Internet son protocolos posteriores que, al igual que SNA, ofrecen más que un simple control de enlace.

Un gran número de dispositivos utilizan el protocolo Bisync, algunos de ellos son:

• Unidades de control del subsistema de terminal de visualización IBM 3270 .
• Terminal de transmisión de datos IBM 2780 .
• Control de transmisión IBM 2703 .
• Estaciones de trabajo IBM HASP .
• Sistema informático IBM 1130 .
• Terminal programable IBM 2922 .

Otros proveedores de computadoras ofrecieron su propia variedad de protocolos orientados a bytes similares a Bisync. Algunos protocolos ampliamente utilizados incluyen el Protocolo de Mensajes de Comunicaciones de Datos Digitales de Digital Equipment Corporation , ^{[ 5 ]} y el Protocolo de Sondeo y Selección de Burroughs Corporation .

• comunicación asíncrona

• Análisis detallado del control de enlaces bisincronizados por Charles A. Wilde (nuevo enlace)
• "Bisync, BSC" . Plataforma de conocimiento de conectividad . Hecho por TI . Consultado el 6 de julio de 2006 .Una descripción detallada del protocolo.
• Programación bisync y STR para IBM 1130
• "Protocolos de comunicación de datos" . Sitio de referencia técnica de Telecom Corner . TBI/WebNet, Inc. Octubre de 2004. Consultado el 6 de julio de 2006 .
• "¿Qué es Bisync? Una breve lección de historia" . Serengeti Systems. Archivado del original el 2 de julio de 2009. Consultado el 6 de julio de 2006 .
• IBM Corporation. "Códigos de caracteres DLC de Bisync en el rastreo de comunicaciones en sistemas OS/400 o i5/OS" . Consultado el 7 de junio de 2012 .{{cite web}}: CS1 maint: servicio de archivado obsoleto ( enlace )
• IBM Corporation. Información general - Comunicaciones binarias síncronas, primera edición (PDF) .
• IBM Corporation. Información general - Comunicaciones binarias síncronas, tercera edición, octubre de 1970 (PDF) .