Кратко

  • RFC 1498 различал четыре именуемых объекта: службы или пользователей, узлы, точки подключения к сети и пути.
  • Для достижения службы требовались три связи, а затем идентификатор деятельности или сокета внутри узла.
  • Адрес и маршрут показывают текущие привязки. Они не доказывают подлинность, полномочия, доставку или результат приложения.

Маршрут дошёл только до машины

Можно знать путь до точки подключения, выбрать правильный узел и всё же не обратиться к нужной службе. На одном компьютере одновременно работают разные процессы. Поэтому RFC 1498 уточнял: маршрут к службе включает не только путь к точке подключения узла, но и обозначение деятельности внутри него — например, идентификатор сокета.

Эта последняя деталь разрушает удобную иллюзию, будто адрес уже содержит весь пункт назначения. Адрес доставляет рассуждение к следующей границе; приложение должно пересечь её отдельным способом.

Работа Jerome Saltzer впервые вышла в 1982 году и была переиздана в августе 1993-го как информационный RFC. Она не являлась стандартом. Её задача состояла в том, чтобы дать достаточно понятий для разговора о назначении пакета без смешения вещей с их текущими местами.

Четыре объекта, которые могли иметь имена

Службы — это используемые функции, а пользователи — их клиенты. Узлы — компьютеры, запускающие службы и программы. Точки подключения — порты или места, где узел присоединён к сети. Пути проходят между такими точками через линии и пересылающие узлы.

Обычная триада «имя — адрес — маршрут» оставляла пространство для двусмысленности. В одном контексте адрес означал точку подключения. В более широком толковании адрес службы был именем узла, адрес узла — именем точки, а адрес точки — именем пути.

Форма значения не решала проблему. Печатная строка могла обозначать точку подключения, двоичное число — узел или другой объект. Имя могло быть плоским либо иерархическим, а один объект мог иметь несколько форм. Следовало спрашивать, какой объект назван и где хранится его связь со следующим.

Три связи сохраняли три идентичности

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

Отсюда три последовательные функции: разрешить имя службы в один или несколько узлов, определить точки подключения этих узлов, затем выбрать путь от точки отправителя. RFC называл их разрешением имени службы, локализацией имени узла и службой маршрута.

Каждая функция могла вернуть список. Несколько копий службы, многосвязный узел и альтернативные маршруты создавали варианты, причём качество пути могло изменить выбор узла. Таблицы могли предоставить частичную привязку, оставив окончательное решение снаружи.

Поэтому одна записанная цель не является доказательством единственности. Для истории важны полный набор кандидатов, политика выбора и время состояния.

Таблица DIALOG меняла только среднюю связь

RFC 1498 предлагал строку: Lockheed DIALOG Service работает на узле 5. Имя DIALOG устойчиво связывалось с конкретной службой. «5» устойчиво называло конкретный узел. В легко изменяемой таблице находилась лишь текущая связь службы с узлом.

Замена 5 на 6 переносила выполнение, а не переименовывала службу. Настоящее переименование потребовало бы изменить программы, документацию, записи пользователей и рекламу. Операционная таблица не содержала всю связь имени с реальным объектом.

Отсюда следует ограничение полномочий. Администратор таблицы способен изменить направление запросов, но это не делает его владельцем службы и не доказывает право определять последствия её использования.

Одна 48-битная величина скрыла уровень

В Ethernet один и тот же 48-битный идентификатор можно было считать именем узла и именем точки подключения. Постоянная привязка позволяла перемещать узел без изменения записей, убирала один уровень таблиц и упрощала поиск запасных путей.

Но две отдельно адресуемые точки одного узла в одном Ethernet создавали проблему. Два значения могли выглядеть как два узла; одно значение не позволяло выбрать интерфейс. Исключённая таблица вернулась как ограничение выразительности.

Имена ARPANET NCP создавали противоположную путаницу. Строка вроде RADC-Multics казалась именем узла или службы, но обозначала порт IMP. Переподключение компьютера требовало нового видимого имени либо массовой правки таблиц. Резервная почтовая служба могла быть доступна на другом компьютере, но пользователю приходилось вводить якобы другое имя службы, потому что исходное имя находилось на уровне подключения.

Сжатый ответ не отменял промежуточные факты

Один сервер имён мог сразу вернуть точки подключения по имени службы, механически объединив первые две связи. Распределённая маршрутизация могла незаметно выполнить третью. Но при отказе всё равно надо выяснить отдельно: где работала служба, где был подключён узел и какой путь существовал.

RFC 1958 позднее советовал приложениям использовать имена вместо жёстко заданных адресов и поддерживал модульность. RFC 2101 разделил требования идентификатора и локатора, назвав их совмещение в адресах IPv4 исторически обусловленным фактом. RFC 2956 зафиксировал проблемы смешения идентичности узла с местом доставки. Это последующие сопоставления, а не поправки к RFC 1498.

Сам RFC 1498 прямо не рассматривал безопасность. Даже правильный сокет не аутентифицирует сторону, не выдаёт полномочий и не подтверждает ответ. Нужны отдельные квитанции транспорта, приложения и внешнего действия.

Работы Heng Lu о первичности работающего кода, локализованном будущем решении и слоях реальности уточняют границу: координационная запись помогает совместной работе, но не становится самим объектом или постоянной властью над операторами.

Полное доказательство хранит пространство имён, время запроса, все узлы и точки, топологию, политику маршрута, выбранный путь, сокет, сеанс и ответ приложения. Маршрут приближает пакет к службе. Он не имеет права рассказывать, что произошло после прибытия.

Источники