Кратко

  • RFC 935 разбирал предложения RFC 914 и RFC 916 для надёжной связи по медленным асинхронным линиям. Робинсон сопоставил кадры с символьными границами, битовыми флагами и полем длины, а затем предложил прозрачное символьное обрамление, 16-битную CRC и процедуры управления LAPB.
  • На коротком кадре RATP экономил два служебных символа по сравнению с комбинацией распространённых процедур. Робинсон предложил проверить, окупит ли этот выигрыш новый протокол вместе с расходами на восстановление связи, программную реализацию и оборудование.

Считать байты проще, чем последствия

RFC 914 описывал Thinwire для подключения персонального компьютера через медленную линию. RFC 916 предлагал RATP для надёжной асинхронной передачи. У разработчиков была веская причина беречь пропускную способность. Робинсон спорил не с причиной, а с границей бухгалтерии: если считать только символы в исправном кадре, новый формат почти всегда можно выставить победителем.

Его цифры заслуживают точного чтения. Отправная величина — 13 байт Thinwire II до добавления служебной части канала. Восемь дополнительных символов равны 8/13, или 61 проценту, и доводят передачу до 21 символа; шесть у RATP равны 6/13, или 46 процентам, и доводят её до 19. При приблизительно 120 переданных символах в секунду 120 × 13/21 дают около 74 символов Thinwire, а 120 × 13/19 — около 82. В этом сценарии только один из 13 символов Thinwire соответствует вводу пользователя; поэтому Робинсон оценивает около 5,6 и 6,3 набранных символа в секунду. Это сравнение при заданных предпосылках, а не результаты испытания сети.

Победа в столь узком примере не оплачивает автоматически написание и сопровождение нового правила для каждого устройства.

Разные способы задавать границу кадра по-разному теряют синхронизацию при ошибке. Символьные протоколы ставят специальные знаки начала и конца и экранируют их появление внутри данных. Битовые используют флаг и вставку битов; обычная среда для них синхронная. DDCMP кладёт число символов в заголовок, избегая экранирования данных. Повреждённый счётчик лишает приёмник ориентира: потребуется проверка заголовка и способ найти следующий. Робинсон отказался считать экранирование постоянной ценой. В сравнении нужно учитывать и время, которое протокол с полем длины тратит на поиск новой границы после ошибки.

Шум на линии распределяет расходы иначе, чем таблица для целых кадров.

Контрольное поле тоже нуждается в защите

Новые предложения использовали простые суммы или XOR. Их удобно вычислять на скромном процессоре. Робинсон настаивал на 16-битной CRC в канале. Если ошибка затронет управляющее поле, кадр можно потерять или получить дважды; исправление на уровне TCP займёт время. Он объяснял, что CRC и проверки TCP/IP чувствительны к разным сочетаниям ошибок, тогда как две похожие суммы разделяют уязвимые комбинации битов. Программную CRC он оценивал примерно в пять-шесть инструкций на символ с таблицей, при потоке около 120 символов в секунду. На шлюзе подобную работу мог выполнять последовательный контроллер.

Предложение RFC 935 объединяло формат DLE STX … DLE ETX CRC CRC с управлением LAPB. Подтверждение могло ехать вместе с обратным потоком, а в каждом направлении одновременно ожидали ответа до семи кадров. Поле адреса для многоточечной связи на линии между двумя участниками лишнее. Робинсон всё же сохранял его: удаление нарушило бы совместимость с уже реализованными процедурами. Итог — восемь служебных символов на кадр. Отказ от поля или переход к счётчику RATP сокращал запись на проводе, но создавал особый вариант, который пришлось бы поддерживать всем.

В конце автор заметил сходство с доступом Telenet примерно 1976 года и предсказал скорую роль X.25/X.32. Это прогноз Робинсона из 1985-го. Его записка не сообщает, какое решение позже победило в промышленности. Зато она ясно показывает цену красивого исключения: производителю микросхем выгодно поддерживать распространённую процедуру, а самодельную договорённость приходится заново внедрять, проверять и чинить при каждом сбое.

Источники