La comunicación binaria síncrona ( 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. La transcodificación de seis bits miró hacia atrás a los sistemas más antiguos; USASCII con 128 caracteres y EBCDICcon 256 caracteres esperado. La transcodificación desapareció muy rápidamente, pero los dialectos EBCDIC y USASCII de Bisync continuaron en uso.
En un momento, Bisync fue el protocolo de comunicaciones más utilizado [1] y todavía tiene un uso limitado en 2013. [2] [3]
Enmarcado
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 encuadre, pero solo existe un formato de trama dentro de un protocolo específico. Bisync tiene cinco formatos de encuadre diferentes. [ cita requerida ]
Carbonizarse | EBCDIC (hexadecimal) | USASCII (hexadecimal) | Transcodificar (hexadecimal) | Descripción |
---|---|---|---|---|
SYN | 32 | dieciséis | 3A | Inactivo sincrónico |
SOL | 01 | 01 | 00 | Inicio del encabezado |
STX | 02 | 02 | 0A | Inicio del texto |
ETB | 26 | 17 | 0F | Fin del bloque de transmisión |
ETX | 03 | 03 | 2E | Fin del texto |
EOT | 37 | 04 | 1E | Fin de transmisión |
ENQ | 2D | 05 | 2D | Consulta |
NAK | 3D | 15 | 3D | Reconocimiento negativo |
DLE | 10 | 10 | 1F | Escape de enlace de datos |
ITB | 1F | 1F (EE. UU.) | 1D (EE. UU.) | Carácter de verificación de bloque intermedio |
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 (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 una sincronización de bytes tentativa. Si el siguiente carácter también es un SYN, se ha logrado la sincronización de caracteres. A continuación, el receptor busca un personaje que pueda iniciar una trama. 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. El receptor los ignora.
Un carácter de final de bloque normal (ETB o ETX) va seguido de una suma de comprobación (carácter de comprobación de bloque o BCC). Para USASCII, esta es una verificación de redundancia longitudinal de un carácter (LRC); para Transcode y EBCDIC, la suma de verificación es una verificación de redundancia cíclica de dos caracteres (CRC). 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 una trama de datos larga permite una mejora considerable de la probabilidad de detección de errores. Los caracteres USASCII también se transmiten usando paridad impar para verificación adicional.
Se requieren caracteres de almohadilla después de un cambio de línea: NAK, EOT, ENQ, ACK0, ACK1. Si la transmisión termina con EOT o ETX, la almohadilla sigue al BCC. Esta almohadilla está compuesta por bits "1" o bits "0" y "1" alternados. La siguiente transmisión comienza con un carácter de pad que puede ser uno de los anteriores o un SYN.
Un encabezado opcional que contiene información de control puede preceder a los datos en un marco. El contenido del encabezado no está definido por el protocolo, pero está definido para cada dispositivo específico. El encabezado, si está presente, está precedido por un carácter SOH (comienzo del encabezado) y seguido por un STX (comienzo del texto). [4]
Los datos de texto normalmente siguen el encabezado, comenzados por STX y terminados por ETX (final del texto) o ETB (final del bloque de transmisión).
Los marcos de datos normales no permiten que ciertos caracteres aparezcan en los datos. Estos son los caracteres finales del 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 entramado de datos transparente proporciona un alfabeto sin restricciones de 64, 128 o 256 caracteres. En el modo transparente, los caracteres de entramado 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 relleno de bits .
Control de enlaces
El protocolo de control de enlace es similar a STR. Los diseñadores intentaron protegerse contra simples errores de transmisión. El protocolo requiere que todos los mensajes sean reconocidos (ACK0 / ACK1) o negativamente reconocidos (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 dañada, una trama de datos perdida y un reconocimiento perdido.
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 un número de serie, se considera posible que una trama de datos se pierda sin que el receptor se dé cuenta. Por lo tanto, se implementan ACK0 y ACK1 alternos; Si el transmisor recibe un 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 un marco de datos.
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 "cambio de sentido" incluso para los fines más simples, como los acuses de recibo. El cambio implica
- la inversión de la dirección de transmisión,
- inactividad del eco de línea,
- resincronización.
En un entorno de 2 cables, esto provoca un notable retraso de ida y vuelta y reduce el rendimiento.
Algunos conjuntos de datos admiten la operación de dúplex completo , y el dúplex completo (4 cables) se puede utilizar en muchas circunstancias para mejorar el rendimiento al eliminar el tiempo de respuesta, a costa de la instalación y el soporte de 4 cables. En el típico dúplex completo, los paquetes de datos se transmiten a lo largo de un par de cables, mientras que los reconocimientos se devuelven a lo largo del otro.
Topología
Gran parte del tráfico de Bisync es de punto a punto . Las líneas de punto a punto pueden utilizar opcionalmente 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 oferta y prepararse para recibir, o NAK o WABT para rechazar. En algunos casos, la conexión de un terminal a varios hosts es posible a través de la red telefónica de marcación.
Multi-drop es parte del protocolo Bisync inicial. Una estación maestra, normalmente una computadora, puede sondear secuencialmente terminales que están conectados a través de puentes analógicos a la misma línea de comunicación. Esto se logra enviando un mensaje que consta solo de un carácter ENQ dirigido a cada dispositivo por turno. La estación seleccionada luego transmite un mensaje al maestro o responde con EOT para indicar que no tiene datos para transmitir.
Aplicaciones Bisync
El propósito original de Bisync era para las comunicaciones por lotes entre un mainframe System / 360 y otro mainframe o un terminal de Entrada de Trabajo Remoto (RJE) como el IBM 2780 o 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ínea de impresión 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 a la 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 el CICS de IBM y el software de terceros como Remote DUCS (sistema de control de la unidad 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 apogeo.
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 alquilada. A mediados de 1990, el BSC fue reemplazado por la infraestructura X.25 .
Aplicaciones pseudo-Bisync
Algunos sistemas importantes utilizan el entramado de datos Bisync con un protocolo de control de enlace diferente. Houston Automatic Spooling Priority (HASP) utiliza hardware Bisync half-duplex junto con su propio protocolo de control de enlace para proporcionar comunicación full-duplex de múltiples flujos de datos 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 las tramas de datos Bisync transparentes encapsulaban paquetes de control y datos HDLC LAPB . A partir de 2012[actualizar], varios proveedores encapsulan las transmisiones Bisync dentro de los flujos de datos TCP / IP.
Disposición
Bisync comenzó a ser reemplazado 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 simple control de enlaces.
Dispositivos Bisync
Una gran cantidad de dispositivos utilizan el protocolo Bisync, algunos de ellos son:
- Unidades de control IBM 3270 Display Terminal Subsystem.
- 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 .
Ver también
- Comunicación asíncrona
Referencias
- ^ Scuilli, Joseph A. (26 de octubre de 1981). "La conmutación terrestre a satélite crea opciones" . Computerworld . Consultado el 27 de agosto de 2012 .
- ^ Cisco. "Comunicaciones binarias síncronas y asíncronas (Bisync / Async)" . Consultado el 23 de octubre de 2013 .
- ^ Gartner. "Comunicaciones binarias síncronas (BSC)" . Glosario de TI . Consultado el 23 de octubre de 2013 .
- ^ IBM Corporation. Información general - Comunicaciones binarias síncronas (PDF) .
Otras lecturas
- Discusión detallada del control de enlaces Bisync por Charles A Wilde (nuevo enlace)
- "Bisync, BSC" . Plataforma de conocimiento de conectividad . Lo hizo . 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 desde el original el 2 de julio de 2009 . Consultado el 6 de julio de 2006 .
- IBM Corporation. "Códigos de caracteres Bisync DLC en el rastreo de comunicaciones en OS / 400 o sistema i5 / OS" . Archivado desde el original el 26 de enero de 2013 . Consultado el 7 de junio de 2012 .
- IBM Corporation. Información general - Comunicaciones binarias síncronas, primera edición (PDF) .
- IBM Corporation. Información general: comunicaciones binarias sincrónicas, tercera edición, octubre de 1970 (PDF) .
Este artículo se basa en material extraído del Diccionario gratuito de informática en línea antes del 1 de noviembre de 2008 e incorporado bajo los términos de "renovación de licencias" de la GFDL , versión 1.3 o posterior.