Протокол B - B protocol

Протокол B
Протокол связи
Цель протокол передачи файлов
Разработчики) Информационная служба CompuServe
Введено 1979 ; 42 года назад  ( 1979 )
Аппаратное обеспечение модемы

Протокол B , или CIS B , представляет собой протокол передачи файлов, разработанный для информационной службы CompuServe и реализованный в 1981 году. Позднее протокол был расширен в версии QuickB (которая была асинхронной версией стандартного протокола), а позже - в расширенной версии B. Плюс версия. Это был довольно продвинутый протокол для своей эпохи, поддерживающий эффективную передачу файлов, команд и других данных, и его можно было использовать в обоих направлениях одновременно в определенных режимах. Эти расширенные функции широко не использовались, но их можно было найти в небольшом количестве клиентских пакетов.

Поскольку протокол B был разработан только для работы в CompuServe, большинство сторонних коммуникационных клиентов того времени были несовместимы с ним. Исключения были Tera Term и Datastorm «s ProComm Plus на ПК , который показал способность слушать для Enquire команды на порт активной связи, и ZTerm на Mac , что позволило автоматически запускаемым передач. Это развитие было частью более широкой тенденции использования внешних коммуникационных приложений в сочетании с онлайн-сервисами.

Описание

Первоначальная версия протокола B была результатом более раннего двунаправленного протокола, представленного в 1979 году, с добавлением опций для включения стандартизованной структуры команд в поток. Этот протокол был предназначен для использования пользовательским онлайн-терминалом, созданным Тэнди , «AgVision» или «VideoTex», но от этого проекта отказались после того, как он был продан лишь на короткий период времени. Система AgVision без модема стала основой Цветного компьютера TRS-80 .

Позднее протокол был расширен в версии B Plus, хотя было две версии этой версии. B Plus сфокусировал общую концепцию в первую очередь на поддержке загрузки с CompuServe, а не на передаче от пользователя к пользователю. Следующее описание основано на документации B Plus и не имеет явной ссылки на более ранний (и редкий) B.

Структура пакета

B Plus - это протокол скользящего окна с пакетами переменного размера от 128 до 2048 байтов и окнами из одного или двух пакетов. Добавление блоков размером 1k и 2k и раздвижных окон было основными изменениями в структуре между B и B Plus. Все потенциально проблемные управляющие символы всегда цитировались , что является требованием, потому что многие люди обращались к CompuServe через не-8-битные сервисы пакетов, такие как Tymnet . B Plus также использовал любой из четырех типов проверки ошибок.

Базовая структура пакета состояла из пяти частей:

Структура пакета B Plus
Привести в <DLE>B
Последовательность # От <0x30> до <0x39>
Тип Однобайтный
Тело от нуля до 2048 байтов
Трейлер <ETX> Проверить значение
(может сопровождаться <RS> )

Введение служит той же цели, что и «заголовок» в большинстве протоколов, указывая на то, что следующие данные являются пакетом B Plus. Порядковый номер - это простой способ убедиться, что пакеты принимаются в правильном порядке при приеме. Используемый небольшой диапазон чисел не представляет проблемы, потому что пакеты, даже «один не в порядке», вызовут повторную отправку или прервут, поэтому нет возможности получить «неправильный 0x30» десятью пакетами позже.

Персонажи в теле или трейлере "цитируются". Официально только несколько символов в кавычках, <ETX> , <ENQ> , <DLE> , <DC1> (XON), <DC3> (XOFF) и NAK . Как правило , три другие символы цитируются , а также, <RS> , <DC1> + 0x80 и <DC3> + 0x80. Символы заключаются в кавычки, добавляя к их порядковому номеру 0x40 и ставя перед ними префикс <DLE> символа. Например, <ETX> символ (0x03) будет отправлен как <DLE>C .

Проверочное значение было процитировано, как и содержимое, по которому оно проверялось, но значение внутри было проверкой значений без кавычек . Это означает, что тело должно быть извлечено и не заключено в кавычки, прежде чем контрольное значение может быть вычислено на принимающей стороне. Было разрешено четыре типа контрольных значений: исходная контрольная сумма XMODEM , слегка измененная версия проверки циклическим избыточным кодом (CRC), используемая в XMODEM-CRC , или CCITT CRC-16 или CRC-32. При использовании CCITT CRC трейлер также включал необязательный символ в конце как "сетевой разрыв" (отправить сейчас), хотя неясно, почему это не поддерживалось с другими типами трейлеров. <RS>

Типы пакетов

B Plus определил несколько разных типов пакетов, в отличие от большинства протоколов, которые включали только один. Эти пакеты использовались как для передачи данных, так и для безопасной доставки команд и информации о настройке протокола. Четыре типа были:

Типы пакетов B Plus
Транспортные параметры +
Передача файлов T
Данные N
Отказ F

Наиболее распространенными пакетами с точки зрения общего количества переданных являются Т-пакеты, содержащие данные для передачи файлов. Эти пакеты не имеют дополнительной семантической ценности и отформатированы, как описано выше. Пакеты T также включают в себя «подтипы», Tr для «возобновления передачи», TF для «сбоя передачи», если резюме не соответствовало частично загруженному файлу, и TI для «информации о передаче», которая отправляла сведения о передаваемом файле. Большинство протоколов отправляли бы информацию о файле в виде специального «нулевого пакета» в самом потоке передачи, тогда как в B Plus это обрабатывалось отдельным типом пакета и фактически из самого потока передачи, хотя на практике не было реальной разницы.

Пакет Failure позволяет отправителю указывать на различные проблемы в потоке пакетов. Пакет обычно содержит один «известный» символ, но может также включать информационное сообщение, следующее за этим символом. Самый распространенный пакет Failure - это A (bort), позволяющий пользователю завершить передачу по запросу. Другие сбои включали, среди прочего, (C) сбой емкости (не хватает места на диске) и (M) файл Issing.

Транспортные параметры обычно отправляются только один раз на этапе начального соединения. Этот пакет содержал ряд деталей в известном формате, который синхронизировал, какие функции могут использовать оба конца соединения. Например, именно на этом этапе был выбран тип контрольного значения.

Транспортный уровень

В дополнение к обычным типам пакетов, описанным выше, B Plus также включает отдельные типы для отправки команд в CIS через уровень исправления ошибок B Plus. Пакет M был одним пакетом данных, в то время как L также был пакетом данных, но указывал, что поток данных теперь завершен. Это должно было быть указано таким образом, потому что, в отличие от передачи файлов, объем отправляемых данных не будет известен заранее.

Содержимое этих пакетов было в свободной форме и не было определено в самой документации B Plus. Однако основная концепция заключалась в том, что программа терминала пользователя будет реагировать на последовательность запросов CIS (отправленную при первом входе пользователя в систему), начиная передачу с типом M. Этот поток будет использоваться для отправки команд узлу CIS, который откликнется, открыв другой поток транспортного уровня обратно в программу терминала. Эти потоки были «беспоследовательными» и считывались в том порядке, в котором они были получены. Пакеты с ошибками или сбоями вызвали прерывание работы обоих каналов.

Возможно, единственным пользователем транспортного уровня был собственный интерфейс Host-Micro Interface (HMI) API CompuServe . HMI определил ряд команд, которые можно использовать для управления CIS, а также возможные ответы на них, минуя интерфейс командной строки . Поскольку исправление ошибок использовалось как побочный эффект создания на B Plus, возможность неправильной интерпретации команд или потенциально искаженных ответов была в основном устранена. CIS расширил HMI, чтобы позволить управлять большей частью пакетно-ориентированного интерфейса, включая функции для электронной почты, конференций и передачи файлов.

Потоки транспортного уровня не могли выполняться одновременно с передачей файлов, поэтому в целом приложения, использующие транспортный уровень, были довольно модальными. Например, CIS Navigator для Mac , основанный на человеко-машинном интерфейсе, позволял пользователям перемещаться по CIS в автономном режиме, настраивая различные передачи электронной почты и файлов, которые затем выполнялись одним пакетом, чтобы сократить время работы в сети. Последним шагом "запуска" навигатора будет загрузка файлов перед выходом из системы.

Последовательности управления

Все протоколы используют «обратный канал» для отправки информации о статусе от «получателя» обратно «отправителю». B Plus формализовала эту систему, определив несколько «сообщений», которые могут быть отправлены вне структуры пакета. К ним относятся типичный, DLE за которым следует порядковый номер, чтобы подтвердить правильный прием пакета. NAK был использован для обозначения неправильно принятого пакета, который откликнулся с подтверждения сообщений, <DLE><DLE> . <DLE>; приостановил отправителя, а <DLE>+ поток прервал.

Управляющая последовательность Inquire уникальна для B Plus. Состоящий из одного <ENQ> , Inquire использовался как для запуска передачи, так и для перезапуска после получения файла NAK . В обоих случаях Inquire заставлял получателя сбрасывать режим соединения до самых основных возможных настроек передачи и готовиться к передаче.

Смотрите также

Рекомендации

  • Расс Рэншоу, "Протокол CompuServe B Plus", 18 ноября 1993 г.
Версия этого документа в формате zip доступна как bplus.zip .
  • Леви Томас и Ник Тернер, «Протокол компьютера B», журнал доктора Добба , том 11, выпуск 7 (июль 1986 г.), стр. 54–59