[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Программирование, языки" / Оглавление документа

Имена, адреса, порты и тому подобное

Практически вся сложность процедур клиент/сервер в MPI объясняется вопросом: Как клиент может определить способ контакта с сервером? Трудность, конечно, состоит в первичном отсутствии между ними канала связи, поэтому они как-то должны договориться о точке рандеву, где они смогут установить соединения - Catch 22.

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

В идеале MPI может приспособиться к широкому кругу систем выполнения при сохранении возможности написания простого переносимого кода. Следующие утверждения будут справедливы для MPI:

• Сервер расположен по хорошо известному адресу Internet на host:port.
• Сервер выводит адрес на терминал, а пользователь указывает этот адрес программе-клиенту.
• Сервер размещает информацию об адресе на сервере имен.
• Сервер, с которым клиент соединяется в действительности, является брокером, работающим как посредник между клиентом и действительным сервером.

Поскольку MPI не требуется сервер имен, не все реализации могут поддерживать все вышеупомянутые сценарии. Однако, MPI предлагает необязательный интерфейс сервера имен и совместим с внешними серверами имен.

Port_name является поддерживаемой системой строкой, которая кодирует низкоуровневый сетевой адрес, по которому сервер может быть доступен. Обычно это IP-адрес и номер порта, но реализация свободна использовать любой протокол. Сервер устанавливает port_name с помощью процедуры MPI_OPEN_PORT. Он принимает соединение с данным портом посредством MPI_COMM_ACCEPT. Клиент использует port_name для связи с сервером.

Сам по себе, механизм port_name полностью переносим, но он может казаться грубым для использования из-за необходимости сообщать port_name клиенту. Более удобно, если сервер может определить, что он известен поддерживаемому приложением service_name, так что клиент сможет соединяться через service_name, не зная port_name.

Реализация MPI может позволить серверу опубликовать пару (port_name, service_name) с помощью MPI_PUBLISH_NAME, и позволить клиенту восстановить имя порта по имени сервиса через MPI_LOOKUP_NAME. Этот подход обеспечивает три уровня переносимости с увеличением уровня функциональности.

1. Приложения, которые не в состоянии публиковать имена, наиболее переносимы. Обычно port_name должно переноситься от сервера к клиенту ``вручную''.
2. Приложения, использующие механизм MPI_PUBLISH_NAME полностью переносимы среди реализаций, предоставляющих этот сервис. Чтобы стать переносимыми среди всех реализаций, эти приложения должны иметь механизм отката, который будет использоваться для неопубликованных имен.
3. Приложения могут игнорировать возможности опубликования имен в MPI и использовать свои собственные механизмы (возможно, поддерживаемые системой) для публикации имен. Этот подход обеспечивает произвольную гибкость, но не является переносимым.

Партнёры:

Хостинг: