Кратко

  • RFC 873 оспаривал надежду сэкономить на закупках Министерства обороны США, дождавшись протоколов по модели ISO с поддержкой производителей: полного набора в 1982 году ещё не было.
  • Разрешённая стандартом дополнительная функция могла присутствовать у одного поставщика и отсутствовать у другого; после поставки цену согласования, вероятнее всего, оплатил бы покупатель.

Фраза «поддерживается поставщиком» прекрасно смотрится в контракте. Сетевой пакет не читает контракт: ему нужен согласованный ответ на другом конце линии. Эту разницу Michael A. Padlipsky положил в основу RFC 873, опубликованной в сентябре 1982 года. В Министерстве обороны США обсуждали, стоит ли ждать протоколов по эталонной модели ISO, которые будут поставлять производители, вместо использования уже работающего набора по модели ARPANET. У сторонников ожидания был понятный довод: государство могло бы потратить меньше. Padlipsky предложил проверить, из каких строк сложится окончательный счёт.

Первая строка — состав покупки. X.25 был хорошо узнаваемым названием, но, по его оценке, решал лишь часть задач связи. Для совместного использования ресурсов разных компьютеров требовались и другие службы. Добавление соседних спецификаций не превращало их автоматически в завершённый набор; разработки National Bureau of Standards и ISO к тому же различались. На бумаге отдел закупок мог поставить галочку напротив «полного комплекта». В технической работе несколько важных страниц комплекта ещё лежали на разных столах. Красивая коробка с пустым местом под будущие инструкции оставалась красивой коробкой.

Вторая строка — календарь. Военные закупки и без того шли долго. В сентябре 1982 года набор по модели ISO, как писал Padlipsky, ещё не был готов полностью, а отдельные части существовали в виде предложений без практической проверки. Работа над стандартами занимала годы, тогда как договоры нужно было заключать сейчас. Протоколы по модели ARPANET уже имели реализации на нескольких операционных системах, которыми пользовалось ведомство. Их следовало сопровождать и адаптировать; это тоже труд. Однако работающий код и обещание будущего кода занимали в графике закупки разные места.

Его оценка более ранней доступности первого варианта была доводом участника спора, а не опубликованным измерением сроков.

Затем Padlipsky разобрал само слово «поддержка». Эталонная модель задавала устройство слоёв, но для двух приобретённых систем требовалось больше определённости. Как срочные данные проходят к приложению? Обязан ли каждый обмен последовательно пройти все слои? Может ли один слой включать несколько протоколов? Что точно означает граница между ними? В RFC 873 эти вопросы превращали общий рисунок архитектуры в перечень проверок при покупке. Два поставщика могли принять разные разумные ответы. Схема на стене от этого не менялась, а посылка между машинами застревала.

Самый наглядный случай — необязательная функция. Одна реализация опирается на возможность, разрешённую спецификацией. Другая реализация обходится без неё. Оба коллектива могут честно следовать тексту стандарта и успешно пройти собственные испытания. Проблема появляется там, где заказчик соединяет продукты: для ожидаемого обмена требуется изменение настройки или программы. Кто оплатит работу? Padlipsky предполагал, что счёт придёт пользователю. «Необязательно» относилось к выбору разработчика; для того, кому нужна действующая сеть, расходы вдруг становятся весьма обязательными.

Ещё одна строка возникает внутри компьютера. Память и процессорное время были ограниченными ресурсами на машинах, которыми сеть позволяла совместно пользоваться. Padlipsky обсуждал затраты на прохождение слоёв, хранение состояний и служебный обмен. Он привёл исторический эпизод с частыми проверочными сообщениями и счётом за работу Multics. Это рассказ о конкретной ситуации, а не универсальный тест производительности будущих реализаций. Его практический смысл для покупателя ясен: спрашивать о расходе ресурсов во время работы, даже если само программное обеспечение приходит в комплекте с оборудованием.

Резкий тон эссе легко запомнить, но его расчёт обходился без злых поставщиков. Разные решения специалистов, разные сроки готовности и разные наборы функций способны создать несовместимость без чьего-либо умысла. За исправление, сопровождение, память и время процессора платят отдельно. В конце Padlipsky заметил, что всё больше производителей уже предлагают TCP/IP или собираются это делать. Граница между «поддержкой поставщика» и действующими протоколами ARPANET к тому времени сама начинала смещаться.

RFC 873 оставляет нам снимок закупочного выбора 1982 года. Он начинается с нескольких скучных и очень полезных вопросов: какой полный набор уже существует, на каких машинах он работает, какие дополнительные возможности совпадают у обоих концов и кто исправит расхождение? Имя поставщика можно вписать в заказ одной строкой. Согласованное поведение двух систем приходится показывать в испытании.