El protocolo B , o CIS B , es un protocolo de transferencia de archivos desarrollado para el Servicio de Información CompuServe e implementado en 1981. El protocolo se amplió más tarde en la versión QuickB (que era una versión asincrónica del protocolo estándar) y más tarde en la versión mejorada B Plus . Era un protocolo bastante avanzado para su época, que también admitía transferencias eficientes de archivos, comandos y otros datos, y podía usarse en ambas direcciones al mismo tiempo en ciertos modos. Estas características avanzadas no se usaban ampliamente, pero se podían encontrar en una pequeña cantidad de paquetes del lado del cliente.
Dado que el protocolo B se diseñó para funcionar únicamente dentro de CompuServe, la mayoría de los clientes de comunicaciones de terceros de la época no eran compatibles con él. Las excepciones notables fueron Tera Term y ProComm Plus de Datastorm en la PC, que ofrecían la capacidad de escuchar el comando en el puerto de comunicaciones activo, y ZTerm en la Mac, que permitía transferencias de inicio automático. Este desarrollo fue parte de una tendencia más amplia de uso de aplicaciones de comunicaciones externas junto con servicios en línea.Enquire
La versión original del Protocolo B fue una consecuencia de un protocolo bidireccional anterior introducido en 1979, que añadía opciones para incluir una estructura de comandos estandarizada en el flujo. Este protocolo estaba pensado para su uso en un terminal en línea personalizado creado por Tandy , el "AgVision" o "VideoTex", pero este proyecto se abandonó después de venderse solo por un breve período. El sistema AgVision, con el módem eliminado, se convirtió en la base del ordenador en color TRS-80 .
El protocolo se amplió posteriormente en la versión B Plus, aunque hubo dos revisiones de esta versión. B Plus centró el concepto general principalmente en admitir descargas desde CompuServe, en lugar de transferencias de usuario a usuario. La siguiente descripción se basa en la documentación de B Plus y no hace referencia explícita a la versión anterior (y poco frecuente) de B Plus.
B Plus es un protocolo de ventana deslizante con paquetes de tamaño variable entre 128 y 2048 bytes y ventanas de uno o dos paquetes. La incorporación de tamaños de bloque de 1k y 2k y ventanas deslizantes fueron los principales cambios en la estructura entre B y B Plus. Todos los caracteres de control potencialmente problemáticos siempre se citaban , un requisito porque muchas personas accedían a CompuServe a través de servicios de paquetes que no eran de 8 bits limpios, como Tymnet . B Plus también utilizó cualquiera de los cuatro tipos de verificación de errores.
La estructura básica del paquete constaba de cinco partes:
La introducción cumple la misma función que el "encabezado" en la mayoría de los protocolos, indicando que los datos que siguen son un paquete B Plus. El número de secuencia es una forma sencilla de asegurarse de que los paquetes se reciben en el orden correcto en la recepción. El pequeño rango de números utilizado no presenta un problema porque los paquetes, incluso "uno fuera de orden", provocarán un reenvío o una interrupción, por lo que no existe la posibilidad de que se reciba el "0x30 incorrecto" diez paquetes más tarde.
Los caracteres del cuerpo o del tráiler se "entrecomillan". Oficialmente, solo se entrecomillan unos pocos caracteres: , , , <ETX>( <ENQ>XON ), (XOFF) y . Normalmente, también se entrecomillan otros tres caracteres: , + 0x80 y + 0x80. Los caracteres se entrecomillan añadiendo 0x40 a su valor ordinal y anteponiéndoles el carácter. Por ejemplo, el carácter (0x03) se enviaría como .<DLE><DC1><DC3>NAK<RS><DC1><DC3><DLE><ETX><DLE>C
El valor de verificación se citaba, al igual que el contenido con el que se verificaba, pero el valor dentro era la verificación de los valores no citados . Eso significa que el cuerpo tenía que ser extraído y descitado antes de que el valor de verificación pudiera calcularse en el extremo receptor. Se permitían cuatro tipos de valores de verificación: la suma de verificación XMODEM original , una versión ligeramente modificada de la verificación de redundancia cíclica (CRC) utilizada en XMODEM-CRC o la CCITT CRC-16 o CRC-32. Al utilizar la CCITT CRC, el tráiler también incluía un carácter opcional al final como un "corte de red" (enviar ahora), aunque no está claro por qué esto no se admitía con otros tipos de tráiler.<RS>
B Plus definía varios tipos de paquetes diferentes, a diferencia de la mayoría de los protocolos que incluían solo uno. Estos paquetes se utilizaban tanto para la transferencia de datos como para la entrega segura de comandos e información de configuración del protocolo. Los cuatro tipos eran:
Los paquetes más comunes, en términos de cantidad total transferida, son los paquetes T que llevan los datos para una transferencia de archivos. Estos paquetes no tienen ningún valor semántico adicional y están formateados como se describió anteriormente. Los paquetes T también incluyen "subtipos", Tr para "continuación de transferencia", TF para "error de transferencia" si la reanudación no coincide con el archivo parcialmente descargado y TI para "información de transferencia", que envía detalles sobre el archivo que se está transfiriendo. La mayoría de los protocolos enviarían información de archivo como un "paquete cero" especial en el flujo de transferencia en sí, mientras que en B Plus esto se manejaba mediante un tipo de paquete separado y efectivamente fuera del flujo de transferencia en sí, aunque no había una diferencia real en la práctica.
El paquete Failure permite al remitente indicar diversos problemas dentro del flujo de paquetes. El paquete normalmente contiene un solo carácter "conocido", pero también puede incluir un mensaje informativo después de este carácter. El paquete Failure más común es el A(bort), que permite al usuario finalizar las transferencias a pedido. Otros errores incluyen fallas de capacidad (falta de espacio en disco) y archivos perdidos, entre otros.
Los parámetros de transporte se enviaban normalmente solo una vez, durante la fase de conexión inicial. Este paquete contenía una serie de detalles en un formato conocido que sincronizaba las características que ambos extremos de la conexión podían utilizar. Fue durante esta fase que se seleccionó, por ejemplo, el tipo de valor de verificación.
Además de los tipos de paquetes normales descritos anteriormente, B Plus también incluía tipos separados para enviar comandos al CIS a través de la capa de corrección de errores de B Plus. El paquete M era un único paquete de datos, mientras que L también era un paquete de datos, pero indicaba que el flujo de datos ya estaba completo. Esto se debía indicar de esta manera porque, a diferencia de una transferencia de archivos, la cantidad de datos que se enviaban no se conocía de antemano.
El contenido de estos paquetes era de formato libre y no estaba definido en la documentación de B Plus. Sin embargo, el concepto básico era que el programa de terminal del usuario respondería a la secuencia de interrogación de CIS (enviada cuando el usuario iniciaba sesión por primera vez) iniciando una transferencia con el tipo M. Este flujo se utilizaría para enviar comandos al host CIS, que respondería abriendo otro flujo de capa de transporte de vuelta al programa de terminal. Estos flujos no tenían secuencia y se leían en el orden en que se recibían. Los paquetes de error o falla hacían que ambos canales se interrumpieran.
Posiblemente el único usuario de la capa de transporte era la propia API de la interfaz Host-Micro (HMI) de CompuServe . La HMI definía una serie de comandos que se podían utilizar para controlar CIS, junto con las posibles respuestas a ellos, sin pasar por la interfaz de línea de comandos . Dado que la corrección de errores se utilizaba como un efecto secundario de estar construido sobre B Plus, se eliminó básicamente la posibilidad de interpretar incorrectamente los comandos o de obtener respuestas potencialmente ilegibles. CIS amplió la HMI para permitir el control de la mayor parte de la interfaz orientada a lotes, incluidas las funciones de correo electrónico, conferencias y transferencias de archivos.
Las transmisiones de la capa de transporte no podían realizarse al mismo tiempo que las transferencias de archivos, por lo que, en términos generales, las aplicaciones que utilizaban la capa de transporte eran bastante modales. Por ejemplo, CIS Navigator para Mac , que estaba basado en HMI, permitía a los usuarios navegar por CIS sin conexión, configurando varias transferencias de correo electrónico y archivos que luego se llevarían a cabo en un solo lote para reducir el tiempo en línea. El último paso de la "ejecución" de Navigator sería descargar archivos antes de cerrar la sesión.
Todos los protocolos utilizan el "canal de retorno" para enviar información de estado desde el "receptor" de vuelta al "emisor". B Plus formalizó este sistema, definiendo varios "mensajes" que podían enviarse fuera de la estructura del paquete. Entre ellos se encontraba el típico "mensaje DLEseguido de un número de secuencia" para confirmar la recepción correcta de un paquete. NAKse utilizaba para indicar un paquete recibido incorrectamente, al que se respondía con mensajes de confirmación, <DLE><DLE>. <DLE>;pausaba el remitente, mientras que <DLE>+abortaba el flujo.
La secuencia de control de Enquire parece exclusiva de B Plus. Consiste en un único <ENQ>, y se utilizó para iniciar transferencias y para reiniciar después de recibir un NAK. En ambos casos, Enquire hizo que el receptor restableciera su modo de conexión a la configuración de transferencia más básica posible y se preparara para una transferencia.