Войти
| Протокол связи | |
| Назначение | протокол передачи файлов |
|---|---|
| Разработчик (и) | Информационная служба CompuServe |
| Представлен | 1979; 41 год назад (1979 г.) |
| Аппаратные средства | модемы |
Протокол B или CIS B - это передача файлов протокол, разработанный для CompuServe Information Service и реализованный в 1981 году. Позднее протокол был расширен в версии QuickB (которая была асинхронной версией стандартного протокола) и позже улучшенная версия B Plus . Это был довольно продвинутый протокол для своего времени, поддерживающий эффективную передачу файлов, команд и других данных, и его можно было использовать в обоих направлениях одновременно в определенных режимах. Эти расширенные функции широко не использовались, но их можно было найти в небольшом количестве клиентских пакетов.
Поскольку протокол B был разработан только для работы в CompuServe, большинство сторонних коммуникационных клиентов того времени были несовместимы с ним. Заметными исключениями были Tera Term и Datastorm ProComm Plus на ПК, в которых была возможность прослушивать команду Inquireна ПК. активный порт связи и ZTerm на Mac, позволяющий автоматически запускать передачу. Это развитие было частью более широкой тенденции использования внешних коммуникационных приложений в сочетании с онлайн-сервисами.
Первоначальная версия протокола B была результатом более раннего двунаправленного протокола, представленного в 1979 году, с добавлением опций для включения стандартизованной структуры команд в поток. Этот протокол был предназначен для использования пользовательским онлайн-терминалом, созданным Тэнди, но от этого проекта отказались. Позднее протокол был расширен в версии B Plus, хотя было две версии этой версии. B Plus сфокусировал общую концепцию в первую очередь на поддержке загрузки с CompuServe, а не на передаче от пользователя к пользователю. Следующее описание основано на документации B Plus и не относится явно к более ранней (и редкой) B.
B Plus - это скользящее окно протокол с пакетами переменного размера от 128 до 2048 байтов и окнами из одного или двух пакетов. Добавление блоков размером 1k и 2k и скользящих окон было основными изменениями в структуре между B и B Plus. Все потенциально проблемные управляющие символы всегда цитировались, что является требованием, потому что многие люди обращались к CompuServe через не-8-битные сервисы пакетов, такие как Tymnet. B Plus также использовал любой из четырех типов проверки ошибок.
Базовая структура пакета состояла из пяти частей:
| Вводная | |
| Последовательность № | <0x30>- <0x39> |
| Тип | Однобайтный |
| Тело | от нуля до 2048 байтов |
| Трейлер | |
(может сопровождаться |
Начальная часть служит той же цели, что и «заголовок» в большинстве протоколов, указывает на то, что следующие данные являются пакетом B Plus. Порядковый номер - это простой способ убедиться, что пакеты принимаются в правильном порядке при приеме. Используемый небольшой диапазон номеров не представляет проблемы, потому что даже пакеты «один не в порядке» вызовет повторную отправку или прерывание, поэтому нет возможности получить "неправильный 0x30" десятью пакетами позже.
Символы в теле или трейлере "цитируются". Официально только несколько символов кавычки, NAK. Обычно также заключаются в кавычки три других символа:
. Проверочное значение было заключено в кавычки, как и содержимое, по которому оно проверялось, но значение внутри было проверкой значений без кавычек. Это означает, что тело должно быть извлечено и не заключено в кавычки, прежде чем контрольное значение может быть вычислено на принимающей стороне. Было разрешено четыре типа контрольных значений: исходная контрольная сумма XMODEM , слегка измененная версия циклического контроля избыточности (CRC), используемого в XMODEM- CRC, или CCITT CRC-16, или CRC-32. При использовании CCITT CRC трейлер также включал необязательный символ
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использовался для обозначения неправильно принятого пакета, на который был дан ответ подтверждающими сообщениями,
Управляющая последовательность Inquire уникальна для B Plus. Состоящий из единственного NAK. В обоих случаях Inquire заставлял получателя сбрасывать режим соединения до самых основных возможных настроек передачи и готовиться к передаче.
