Двоичная синхронная связь ( BSC или Bisync ) — символьно-ориентированный полудуплексный протокол связи IBM , анонсированный в 1967 году после появления System/360 . Он заменил протокол синхронной передачи-приема (STR), используемый в компьютерах второго поколения. Цель заключалась в том, чтобы общие правила управления ссылками можно было использовать с тремя различными кодировками символов для сообщений.
Шестибитный транскод обратился к старым системам; USASCII со 128 символами и EBCDIC с 256 символами ждали вперед. Транскод исчез очень быстро, но диалекты Bisync EBCDIC и USASCII продолжали использоваться.
Когда-то Bisync был наиболее широко используемым протоколом связи [1] и до сих пор используется ограниченно в 2013 году. [2] [3]
Bisync отличается от протоколов, пришедших ему на смену, сложностью формирования сообщений. Более поздние протоколы используют единую схему формирования кадров для всех сообщений, отправляемых протоколом. HDLC , протокол передачи цифровых данных (DDCMP), протокол «точка-точка» (PPP) и т. д. имеют разные схемы формирования кадров, но в рамках конкретного протокола существует только один формат кадра. Bisync имеет пять различных форматов кадрирования. [ нужна цитата ]
ACK0 и ACK1 (четное/нечетное утвердительное подтверждение) кодируются двумя символами — DLE '70'x и DLE / для EBCDIC, DLE 0 и DLE 1 для USASCII, DLE - и DLE T для транскодирования. 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-проводной). В этой среде пакеты или кадры передачи строго однонаправлены, что требует «разворота» даже для самых простых целей, таких как подтверждения. Поворот включает в себя
В 2-проводной среде это приводит к заметной задержке передачи и снижению производительности.
Некоторые наборы данных поддерживают полнодуплексный режим, а полнодуплексный (4-проводной) режим можно использовать во многих случаях для повышения производительности за счет устранения времени выполнения работ за счет дополнительных затрат на установку и поддержку 4-проводного режима. В типичном полнодуплексном режиме пакеты данных передаются по одной паре проводов, а подтверждения возвращаются по другой.
Большая часть трафика Bisync является двухточечной . Линии «точка-точка» могут дополнительно использовать конкуренцию для определения главной станции. В этом случае одно устройство может передать ENQ для подачи заявки на управление. Другое устройство может ответить ACK0, чтобы принять заявку и подготовиться к приему, или NAK или WABT, чтобы отказаться. В некоторых случаях подключение терминала к нескольким хостам возможно через коммутируемую телефонную сеть.
Многоточечная передача является частью исходного протокола Bisync. Главная станция, обычно компьютер, может последовательно опрашивать терминалы, подключенные через аналоговые мосты к одной и той же линии связи. Это достигается путем отправки сообщения, состоящего только из символа ENQ, адресованного каждому устройству по очереди. Затем выбранная станция передает сообщение ведущему устройству или отвечает EOT, указывая, что у нее нет данных для передачи.
Первоначальной целью Bisync была пакетная связь между мэйнфреймом System/360 и другим мэйнфреймом или терминалом удаленного ввода заданий (RJE), таким как IBM 2780 или IBM 3780 . Терминалы RJE поддерживают ограниченное количество форматов данных: ввод и вывод изображений перфокарт, а также печать строковых изображений на терминал. Некоторые поставщики оборудования, не принадлежащие IBM, такие как Mohawk Data Sciences, использовали Bisync для других целей, таких как передача с ленты на ленту. Программист может легко эмулировать терминал RJE или другое устройство.
IBM предложила макросы языка ассемблера для обеспечения поддержки программирования. В эпоху System/360 этими методами доступа были BTAM (базовый метод доступа к телекоммуникациям) и QTAM (метод доступа к телекоммуникациям с очередью), который позже был заменен методом доступа к телекоммуникациям (TCAM). IBM представила VTAM (метод виртуального телекоммуникационного доступа) в System/370 .
Мониторы телеобработки , такие как IBM CICS , и стороннее программное обеспечение, такое как Remote DUCS (система управления дисплеем) и платформы Westi, использовали линейное управление Bisync для связи с удаленными устройствами.
Академическая вычислительная сеть Bitnet вместе с соединительными сетями в других географических регионах на пике своего развития использовала Bisync для соединения 3000 компьютерных систем.
Финансовая сеть SWIFT использовала протокол BSC для связи между Региональным центром и сервером учреждения (банка) по выделенной линии. В середине 1990 года BSC был заменен инфраструктурой X.25 .
Некоторые важные системы используют кадрирование данных Bisync с другим протоколом управления каналом. Приоритет автоматической буферизации Хьюстона (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 [ 5] и протокол опроса и выбора корпорации Burroughs .