Двоичная синхронная связь ( BSC или Bisync ) — это символьно-ориентированный полудуплексный протокол связи IBM , анонсированный в 1967 году после появления System/360 . Он заменил протокол синхронной передачи-приёма (STR), использовавшийся в компьютерах второго поколения. Целью было то, что общие правила управления связью можно было использовать с тремя различными кодировками символов для сообщений.
Шестибитный Transcode смотрел назад к более старым системам; USASCII с 128 символами и EBCDIC с 256 символами смотрели вперед. Transcode исчез очень быстро, но диалекты EBCDIC и USASCII Bisync продолжали использоваться.
В свое время Bisync был наиболее широко используемым протоколом связи [1] и по состоянию на 2013 год все еще используется ограниченно. [2] [3]
Bisync отличается от последующих протоколов сложностью кадрирования сообщений. Более поздние протоколы используют единую схему кадрирования для всех сообщений, отправляемых протоколом. HDLC , Digital Data Communications Message Protocol (DDCMP), Point-to-Point Protocol (PPP) и т. д. имеют разные схемы кадрирования, но в рамках конкретного протокола существует только один формат кадра. Bisync имеет пять разных форматов кадрирования. [ необходима цитата ]
ACK0 и ACK1 (четное/нечетное подтверждение) кодируются как два символа — DLE '70'x и DLE / для EBCDIC, DLE 0 и DLE 1 для USASCII, DLE - и DLE T для Transcode. WABT (ожидание перед передачей) кодируется как DLE ", DLE ? или DLE W.
Все форматы кадров начинаются как минимум с двух байтов SYN . Двоичная форма байта SYN обладает тем свойством, что ни один поворот байта не равен исходному. Это позволяет получателю найти начало кадра, просматривая полученный поток битов на предмет шаблона SYN. Когда он найден, предварительная синхронизация байтов достигнута. Если следующий символ также является SYN, синхронизация символов достигнута. Затем получатель ищет символ, который может начать кадр. Символы за пределами этого набора описываются как «ведущая графика». Иногда они используются для идентификации отправителя кадра. В длинные сообщения байты SYN вставляются примерно каждую секунду для поддержания синхронизации. Они игнорируются получателем.
За обычным символом окончания блока (ETB или ETX) следует контрольная сумма (символ проверки блока или BCC). Для USASCII это односимвольный контроль продольной избыточности (LRC); для Transcode и EBCDIC контрольная сумма представляет собой двухсимвольный циклический контроль избыточности (CRC). Кадр данных может содержать промежуточную контрольную сумму, которой предшествует символ ITB. Эта возможность включать промежуточные контрольные суммы в длинный кадр данных позволяет значительно повысить вероятность обнаружения ошибок. Символы USASCII также передаются с использованием нечетной четности для дополнительной проверки.
Символы -заполнители требуются после поворота строки — NAK, EOT, ENQ, ACK0, ACK1. Если передача заканчивается EOT или ETX, заполнитель следует за BCC. Этот заполнитель — это либо все биты «1», либо чередующиеся биты «0» и «1». Следующая передача начинается с символа-заполнителя, который может быть либо одним из вышеперечисленных, либо SYN.
Необязательный заголовок, содержащий управляющую информацию, может предшествовать данным в кадре. Содержимое заголовка не определяется протоколом, но определяется для каждого конкретного устройства. Заголовку, если он присутствует, предшествует символ SOH (начало заголовка), за которым следует STX (начало текста). [4]
Текстовые данные обычно следуют за заголовком, начинаются с STX и заканчиваются ETX (конец текста) или ETB (конец блока передачи).
Обычные кадры данных не допускают появления определенных символов в данных. Это символы окончания блока: ETB, ETX и ENQ, а также символы ITB и SYN. Количество уникальных символов, которые могут быть переданы, поэтому ограничено 59 для Transcode, 123 для USASCII или 251 для EBCDIC.
Прозрачное кадрирование данных обеспечивает неограниченный алфавит из 64, 128 или 256 символов. В прозрачном режиме символы кадрирования блоков, такие как ETB, ETX и SYN, предваряются символом DLE для указания их управляющего значения (сам символ DLE представлен последовательностью DLE DLE). Эта техника стала известна как заполнение символов, по аналогии с битовым заполнением .
Протокол управления связью похож на STR. Разработчики попытались защититься от простых ошибок передачи. Протокол требует, чтобы каждое сообщение было подтверждено (ACK0/ACK1) или отрицательно подтверждено (NAK), поэтому передача небольших пакетов имеет высокие накладные расходы. Протокол может восстановиться после поврежденного кадра данных, потерянного кадра данных и потерянного подтверждения.
Восстановление после ошибки осуществляется путем повторной передачи поврежденного кадра. Поскольку пакеты данных Bisync не имеют серийных номеров, считается возможным, что кадр данных может пропасть без ведома получателя. Поэтому используются чередующиеся ACK0 и ACK1; если передатчик получает неправильный ACK, он может предположить, что пакет данных (или ACK) пропал. Потенциальный недостаток заключается в том, что повреждение ACK0 в ACK1 может привести к дублированию кадра данных.
Защита от ошибок для ACK0 и ACK1 слабая. Расстояние Хэмминга между двумя сообщениями составляет всего два бита.
Протокол является полудуплексным (2-проводным). В этой среде пакеты или кадры передачи строго однонаправлены, что требует «обратного хода» даже для самых простых целей, таких как подтверждения. Обратный ход включает
В двухпроводной среде это приводит к заметной задержке передачи сигнала в обоих направлениях и снижению производительности.
Некоторые наборы данных поддерживают полнодуплексную работу, а полнодуплексная (4-проводная) связь может использоваться во многих обстоятельствах для повышения производительности за счет устранения времени оборота, за счет дополнительных расходов на установку и поддержку 4-проводной связи. В типичном полнодуплексном режиме пакеты данных передаются по одной паре проводов, а подтверждения возвращаются по другой.
Большая часть трафика Bisync является двухточечным . Линии двухточечного соединения могут опционально использовать состязание для определения главной станции. В этом случае одно устройство может передать ENQ для подачи заявки на управление. Другое устройство может ответить ACK0, чтобы принять заявку и подготовиться к приему, или NAK или WABT, чтобы отказаться. В некоторых случаях подключение терминала к нескольким хостам возможно через коммутируемую телефонную сеть.
Multi-drop является частью исходного протокола Bisync. Главная станция, обычно компьютер, может последовательно опрашивать терминалы, которые подключены через аналоговые мосты к той же линии связи. Это достигается путем отправки сообщения, состоящего только из символа ENQ, адресованного каждому устройству по очереди. Затем выбранная станция передает сообщение главной станции или отвечает EOT, чтобы указать, что у нее нет данных для передачи.
Первоначальной целью Bisync была пакетная связь между мэйнфреймом System/360 и другим мэйнфреймом или терминалом удаленного ввода заданий (RJE), таким как IBM 2780 или IBM 3780. Терминалы RJE поддерживают ограниченное количество форматов данных: входные и выходные изображения перфокарт и изображения линий печати на терминале. Некоторые поставщики оборудования, не относящиеся к IBM, такие как Mohawk Data Sciences, использовали Bisync для других целей, таких как передача с ленты на ленту. Программист может легко эмулировать терминал RJE или другое устройство.
IBM предложила макросы языка ассемблера для поддержки программирования. В эпоху System/360 такими методами доступа были BTAM (Basic Telecommunications Access Method) и QTAM (Queued Telecommunications Access Method) – который позже был заменен на Telecommunications Access Method (TCAM). IBM представила VTAM (Virtual Telecommunications Access Method) с System/370 .
Мониторы телеобработки, такие как CICS от IBM , и стороннее программное обеспечение, такое как Remote DUCS (система управления дисплеем) и платформы Westi, использовали управление линией Bisync для связи с удаленными устройствами.
Академическая вычислительная сеть Bitnet , а также соединительные сети в других географических регионах использовали Bisync для соединения 3000 компьютерных систем на пике своей популярности.
Финансовая сеть SWIFT использовала протокол BSC для связи между региональным центром и сервером учреждения (банка) по выделенной линии. В середине 1990-х годов BSC был заменен инфраструктурой X.25 .
Некоторые важные системы используют кадрирование данных Bisync с другим протоколом управления связью. Houston Automatic Spooling Priority (HASP) использует полудуплексное оборудование Bisync в сочетании с собственным протоколом управления связью для обеспечения полнодуплексной многопотоковой связи между небольшим компьютером и мэйнфреймом, работающим под управлением HASP. В терминах Bisync это диалоговый режим .
Некоторые ранние сети X.25 допускали схему соединения, в которой прозрачные кадры данных Bisync инкапсулировали данные HDLC LAPB и пакеты управления. По состоянию на 2012 год [update]несколько поставщиков инкапсулировали передачи Bisync в потоки данных TCP/IP.
Bisync начал вытесняться в 1970-х годах системной сетевой архитектурой (SNA), которая позволяет строить сеть с несколькими хостами и несколькими программами, использующими телекоммуникации. X.25 и протокол Интернета являются более поздними протоколами, которые, как и SNA, обеспечивают больше, чем просто управление соединением.
Большое количество устройств используют протокол Bisync, вот некоторые из них:
Другие поставщики компьютеров предлагали свои собственные разнообразные байт-ориентированные протоколы, похожие на Bisync. Некоторые широко используемые протоколы включают Digital Equipment Corporation 's Digital Data Communications Message Protocol , [5] и Burroughs Corporation 's Poll and Select Protocol .