Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску

Двоичная синхронная связь ( BSC или Bisync ) - это символьный полудуплексный протокол связи IBM , объявленный в 1967 году после появления System / 360 . Он заменил протокол синхронной передачи-приема (STR), используемый в компьютерах второго поколения. Намерение состояло в том, чтобы общие правила управления ссылками могли использоваться с тремя разными кодировками символов для сообщений. Шесть-бит Transcode посмотрел назад , чтобы старые системы; 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 также передаются с использованием нечетной четности для дополнительной проверки.

Pad символов необходимы следующие строки оборачиваемости-NAK, СРВ, 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 [ править ]

Первоначальная цель 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 Дюк (дисплей система блока управления) и Westi платформы используется управление линией BISYNC для связи с удаленными устройствами.

Академическая вычислительная сеть Bitnet вместе с сетями подключения в других географических регионах использовала Bisync для подключения 3000 компьютерных систем на пике своего развития.

Финансовая сеть SWIFT использовала протокол BSC для связи между Региональным центром и сервером учреждения (банка) по выделенной линии. В середине 1990-х годов BSC был заменен на инфраструктуру X.25 .

Приложения Pseudo-Bisync [ править ]

Некоторые важные системы используют кадрирование данных Bisync с другим протоколом управления каналом. Houston Automatic Spooling Priority (HASP) использует полудуплексное оборудование Bisync в сочетании с собственным протоколом управления каналом для обеспечения полнодуплексной связи с несколькими потоками данных между небольшим компьютером и мэйнфреймом, на котором работает HASP. В терминах Bisync это разговорный режим .

Некоторые ранние сети X.25 допускали схему подключения, в которой прозрачные кадры данных Bisync инкапсулировали данные HDLC LAPB и пакеты управления. По состоянию на 2012 год несколько поставщиков инкапсулируют передачи Bisync в потоках данных TCP / IP.

Распоряжение [ править ]

На смену Bisync в 1970-х годах пришла системная сетевая архитектура (SNA), которая позволяет создавать сеть с несколькими хостами и несколькими программами с использованием телекоммуникаций. X.25 и Интернет-протокол - это более поздние протоколы, которые, как и SNA, обеспечивают больше, чем просто управление связью.

Устройства Bisync [ править ]

Большое количество устройств используют протокол Bisync, некоторые из них:

  • Блоки управления подсистемы терминала дисплея IBM 3270 .
  • Терминал передачи данных IBM 2780 .
  • IBM 2703 Управление передачей.
  • Рабочие станции IBM HASP .
  • Вычислительная система IBM 1130 .
  • Программируемый терминал IBM 2922 .

См. Также [ править ]

  • Асинхронная связь

Ссылки [ править ]

  1. ^ Scuilli, Джозеф А. (26 октября 1981). «Переключение с наземного на спутниковое создает возможности» . Компьютерный мир . Проверено 27 августа 2012 года .
  2. ^ Cisco. «Двоичные синхронные и асинхронные коммуникации (Bisync / Async)» . Проверено 23 октября 2013 года .
  3. ^ Gartner. «Двоичная синхронная связь (BSC)» . ИТ-глоссарий . Проверено 23 октября 2013 года .
  4. ^ Корпорация IBM. Общая информация - двоичные синхронные коммуникации (PDF) .

Дальнейшее чтение [ править ]

  • Подробное обсуждение управления ссылками Bisync Чарльзом Уайльдом (новая ссылка)
  • «Bisync, BSC» . Платформа знаний о взаимодействии . Сделал ЭТО . Проверено 6 июля 2006 . Подробное описание протокола.
  • Программирование Bisync и STR для IBM 1130
  • «Протоколы передачи данных» . Технический справочный сайт Telecom Corner . TBI / WebNet, Inc. октября 2004 . Проверено 6 июля 2006 .
  • «Что такое Bisync? Краткий урок истории» . Системы Серенгети. Архивировано из оригинала на 2009-07-02 . Проверено 6 июля 2006 .
  • Корпорация IBM. «Коды символов Bisync DLC в трассировке обмена данными в системе OS / 400 или i5 / OS» . Архивировано из оригинала на 2013-01-26 . Проверено 7 июня 2012 .
  • Корпорация IBM. Общая информация - двоичные синхронные коммуникации, первое издание (PDF) .
  • Корпорация IBM. Общая информация - двоичные синхронные коммуникации, третье издание, октябрь 1970 г. (PDF) .

Эта статья основана на материалах, взятых из Free On-line Dictionary of Computing до 1 ноября 2008 г. и включенных в соответствии с условиями «перелицензирования» GFDL версии 1.3 или новее.