Кратко

  • Служба ONC RPC могла выбрать транспортный порт во время запуска; Portmapper из RFC 1057 давал клиенту постоянную точку, где этот порт можно узнать.
  • Запись связывала номер программы, версию и транспорт с портом на конкретной машине. Это был ответ каталога, а не доказательство личности или доступности службы.

Адрес известен; порт службы может меняться

Представим, что администратор перезапускает файловую службу на компьютере. Процесс сервера может занять свободный порт, а не требовать заранее согласованный номер для всей сети. Но клиент, знающий адрес узла и нужную программу RPC, всё ещё должен понять, куда отправлять вызов. Если всем службам назначать постоянные глобально согласованные порты, ограниченное пространство портов станет тесным реестром для множества меняющихся программ.

RFC 1057, опубликованный Sun Microsystems в июне 1988 года, описал иной порядок. Номер программы и версия сообщали, что хочет вызвать клиент; TCP или UDP задавал транспорт. Локальный Portmapper на общеизвестном порту 111 связывал эти обозначения с портом, выбранным сервером. Клиент сначала обращался к mapper, затем к службе. Вызов RPC и поиск конечной точки были разными действиями.

PMAPPROC_SET служил для регистрации. Сервер передавал mapper на той же машине номер программы, версию, транспортный протокол и порт прослушивания. Mapper отказывал во второй регистрации той же комбинации программы, версии и протокола. Когда служба завершала работу, PMAPPROC_UNSET удалял запись. Клиент обращался к PMAPPROC_GETPORT; ноль означал, что такая комбинация не зарегистрирована.

Распределение ролей было простым: служба выбирала порт для прослушивания, mapper публиковал этот выбор через предсказуемую точку, клиент использовал полученный номер. Конечная точка могла меняться, а способ её узнать оставался известным.

Чего ответ не подтверждал

Ответ mapper отражал только локальную таблицу регистраций. RFC 1057 не превращал GETPORT в сквозную проверку работоспособности, доказательство открытого сетевого пути или криптографическое удостоверение программы на указанном порту. Клиенту всё равно нужно было установить соединение, выполнить RPC-вызов и оценить результат. Если служба остановилась, а запись осталась, запрос мог пройти, а соединение — завершиться неудачей. Если записи нет, не разрешается привязка службы.

«Найдено» звучит надёжнее, чем «зарегистрировано». Номер порта указывает, где служба записала свой адрес прослушивания. Он не гарантирует, что пакеты дойдут, служба примет данного клиента или завершит нужную процедуру. RFC отдельно рассматривает аутентификацию и семантику транспорта; Portmapper их не заменяет.

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

В RFC также описаны PMAPPROC_DUMP, перечислявший записи, и PMAPPROC_CALLIT для широковещательных вызовов. Клиент отправлял запрос на общеизвестный порт mapper по широковещательному адресу. Каждый получивший его mapper мог вызвать локально зарегистрированную службу. RFC предписывал отвечать только при успешном выполнении; в ином случае mapper молчал. Это позволяло обращаться к службам на разных машинах, даже если порты у них различались, но не гарантировало доставку и не давало полного перечня ответивших узлов.

Диапазоны номеров программ задавали отдельную границу координации. RFC 1057 распределял их между определёнными Sun, пользовательскими, временными и зарезервированными блоками. Логическое имя программы не требовалось совмещать с динамическим транспортным портом: один номер обозначал программу RPC, а локально найденное значение указывало, где слушал её экземпляр.

От портов TCP/UDP к универсальным адресам

Первоначальный Portmapper непосредственно работал с портами TCP и UDP. В 1995 году RFC 1833 описал версию 2 Port Mapper, а также версии 3 и 4 RPCBIND. Причина оставалась прежней: транспортный адрес службы мог меняться, а клиенту нужна была известная точка запроса по адресу сервера. RPCBIND представлял транспортные адреса универсальными строками и включал идентификатор сети, расширив привязку за пределы портов TCP/UDP.

Более поздний документ помогает увидеть границу решения 1988 года. RFC 1057 не привязывал программу RPC к единственному порту транспорта. Он задавал точку встречи, связывавшую программу и версию с транспортным слушателем. RFC 5531 позднее также описал протокол сообщений RPC отдельно от механизмов привязки и rendezvous.

Польза была конкретной: если клиент и сервер следовали общей процедуре запроса, клиенту не нужно было заранее знать порт службы. Это экономило фиксированные порты и позволяло каждому экземпляру выбирать локальный адрес. Цена — дополнительный обмен до вызова и состояние, которое должно следовать за запуском, регистрацией, остановкой и удалением службы.

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

Первичные документы: RFC 1057 — RPC Version 2; RFC 1833 — протоколы привязки ONC RPC; RFC 5531 — ONC RPC Version 2.