La comunicación síncrona binaria ( BSC o Bisync ) es un protocolo de enlace semidúplex orientado a caracteres de IBM , anunciado en 1967 después de la introducción de System/360 . Reemplazó el protocolo de transmisión-recepción síncrona (STR) utilizado con las computadoras de segunda generación. La intención era que se pudieran utilizar reglas comunes de gestión de enlaces con tres codificaciones de caracteres diferentes para los mensajes.
Transcode de seis bits miró hacia atrás, a sistemas más antiguos; Se esperaban USASCII con 128 caracteres y EBCDIC con 256 caracteres. Transcode desapareció muy rápidamente pero los dialectos EBCDIC y USASCII de Bisync continuaron en uso.
Hubo un tiempo en que Bisync era el protocolo de comunicaciones más utilizado [1] y todavía tiene un uso limitado en 2013. [2] [3]
Bisync se diferencia de los protocolos que lo sucedieron en la complejidad del encuadre de mensajes. Los protocolos posteriores utilizan un esquema de trama único para todos los mensajes enviados por el protocolo. HDLC , Protocolo de mensajes de comunicaciones de datos digitales (DDCMP), Protocolo punto a punto (PPP), etc. tienen diferentes esquemas de trama, pero solo existe un formato de trama dentro de un protocolo específico. Bisync tiene cinco formatos de encuadre diferentes. [ cita necesaria ]
ACK0 y ACK1 (confirmación afirmativa par/impar) están codificados como dos caracteres: DLE '70'x y DLE / para EBCDIC, DLE 0 y DLE 1 para USASCII, DLE - y DLE T para Transcode. WABT (esperar 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 a la original. Esto permite al receptor encontrar el comienzo de una trama buscando el patrón SYN en el flujo de bits recibido. Cuando se encuentra esto, se ha logrado la sincronización tentativa de bytes. Si el siguiente carácter también es SYN, se ha logrado la sincronización de caracteres. Luego, el receptor busca un personaje que pueda iniciar un cuadro. Los personajes fuera de este conjunto se describen como "gráficos principales". 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 de final de bloque normal (ETB o ETX) va seguido de una suma de verificación (carácter de verificación de bloque o BCC). Para USASCII, esta es una verificación de redundancia longitudinal (LRC) de un carácter; para Transcode y EBCDIC, la suma de verificación es una verificación de redundancia cíclica (CRC) de dos caracteres. Una trama de datos puede contener una suma de verificación intermedia precedida por un carácter ITB. Esta capacidad de incluir sumas de verificación intermedias en un marco de datos largo permite una mejora considerable de la probabilidad de detección de errores. Los caracteres USASCII también se transmiten utilizando paridad impar para una verificación adicional.
Se requieren caracteres de relleno después de un cambio de línea: NAK, EOT, ENQ, ACK0, ACK1. Si la transmisión termina con EOT o ETX, el pad sigue al BCC. Este pad tiene bits '1' o bits '0' y '1' alternos. La siguiente transmisión comienza con un carácter de pad que puede ser cualquiera de los anteriores o SYN.
Un encabezado opcional que contenga información de control puede preceder a los datos en un marco. El contenido del encabezado no está definido por el protocolo sino que se define para cada dispositivo específico. El título, si está presente, está precedido por un carácter SOH (inicio del título) y seguido de un STX (inicio del texto). [4]
Los datos de texto normalmente siguen al encabezado, comenzado por STX y terminado por ETX (fin de texto) o ETB (fin de bloque de transmisión).
Los marcos de datos normales no permiten que aparezcan ciertos caracteres en los datos. Estos son los caracteres de final de bloque: ETB, ETX y ENQ y 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 marco de datos transparente proporciona un alfabeto sin restricciones de 64, 128 o 256 caracteres. En modo transparente, los caracteres de estructura de bloques como ETB, ETX y SYN están precedidos por un carácter DLE para indicar su significado de control (el carácter DLE en sí está representado por 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 simples de transmisión. El protocolo requiere que cada mensaje sea confirmado (ACK0/ACK1) o confirmado negativamente (NAK), por lo que la transmisión de paquetes pequeños tiene una alta sobrecarga de transmisión. El protocolo puede recuperarse de una trama de datos corrupta, una trama de datos perdida y un acuse de recibo perdido.
La recuperación de errores se realiza mediante la retransmisión de la trama corrupta. Dado que los paquetes de datos Bisync no tienen números de serie, se considera posible que se pierda una trama de datos sin que el receptor se dé cuenta. Por lo tanto, se implementan ACK0 y ACK1 alternos; Si el transmisor recibe el ACK incorrecto, puede asumir que se perdió un paquete de datos (o un ACK). Una falla potencial es que la corrupción de ACK0 en ACK1 podría resultar en la duplicación de una trama de datos.
La protección contra errores para ACK0 y ACK1 es débil. La distancia de Hamming entre los dos mensajes es de sólo 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 "cambio de rumbo" incluso para los propósitos más simples, como los acuses de recibo. El cambio de rumbo implica
En un entorno de 2 cables, esto provoca un retraso de ida y vuelta notable y reduce el rendimiento.
Algunos conjuntos de datos admiten la operación full-duplex , y el full-duplex (4 cables) se puede utilizar en muchas circunstancias para mejorar el rendimiento al eliminar el tiempo de respuesta, con el costo adicional de la instalación y el soporte de 4 cables. En el modo full-duplex típico, los paquetes de datos se transmiten a lo largo de un par de cables mientras que los acuses de recibo se devuelven a lo largo del otro.
Gran parte del tráfico Bisync es punto a punto . Opcionalmente, 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 solicitar el control. El otro dispositivo puede responder ACK0 para aceptar la oferta y prepararse para recibir, o NAK o WABT para rechazarla. En algunos casos, es posible conectar un terminal a múltiples hosts a través de la red telefónica.
Multi-drop es parte del protocolo Bisync inicial. Una estación maestra, normalmente una computadora, puede sondear secuencialmente terminales que están conectados mediante puentes analógicos a la misma línea de comunicación. Esto se logra enviando un mensaje que consta únicamente de un carácter ENQ dirigido a cada dispositivo por turno. Luego, la estación seleccionada transmite un mensaje al maestro o responde con EOT para indicar que no tiene datos para transmitir.
El propósito original de Bisync era realizar comunicaciones 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: entrada y salida de imágenes de tarjetas perforadas e imágenes de líneas impresas en el terminal. Algunos proveedores de hardware que no son de 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 ofreció macros en lenguaje ensamblador para brindar soporte de programación. Durante la era System/360, estos métodos de acceso eran BTAM (Método de acceso a telecomunicaciones básico) y QTAM (Método de acceso a telecomunicaciones en cola), que luego fue reemplazado por el Método de acceso a telecomunicaciones (TCAM). IBM introdujo VTAM (Método de acceso a telecomunicaciones virtuales) con el System/370 .
Los monitores de teleprocesamiento , como CICS de IBM y software de terceros, como Remote DUCS (sistema de control de unidad de visualización) y plataformas Westi , utilizaban el control de línea Bisync para comunicarse con dispositivos remotos.
La red informática académica Bitnet , junto con redes de conexión en otras áreas geográficas, utilizó Bisync para conectar 3000 sistemas informáticos en su punto máximo.
La red financiera SWIFT utilizó 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 1990, el BSC fue reemplazado por la infraestructura X.25 .
Algunos sistemas importantes utilizan tramas de datos Bisync con un protocolo de control de enlace diferente. Houston Automatic Spooling Priority (HASP) utiliza hardware Bisync semidúplex junto con su propio protocolo de control de enlace para proporcionar comunicación de múltiples flujos de datos full-duplex entre una computadora pequeña y una computadora central que ejecuta HASP. En términos de Bisync, este es el modo conversacional .
Algunas de las primeras redes X.25 toleraban un esquema de conexión en el que tramas de datos Bisync transparentes encapsulaban datos HDLC LAPB y paquetes de control. A partir de 2012 [update], varios proveedores encapsulan las transmisiones Bisync dentro de flujos de datos TCP/IP.
Bisync comenzó a ser desplazado en la década de 1970 por Systems Network Architecture (SNA), que permite la construcción de una red con múltiples hosts y múltiples programas utilizando telecomunicaciones. X.25 y el Protocolo de Internet son protocolos posteriores que, como SNA, proporcionan más que un mero control de enlaces.
Una gran cantidad de dispositivos utilizan el protocolo Bisync, algunos de estos son:
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 selección y encuesta de Burroughs Corporation .