Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 46
Текст из файла (страница 46)
Во многих случаях важна кооперация с программным обеспечением клиентской стороны. Например, когда клиент уже привязан к серверу, он может напрямую извещаться об изменении местонахождения сервера. В этом случае промежуточный уровень клиента можетскрывать истинное местоположение сервера от пользователя и при необходимости незаметно повторить привязку к этому серверу. Самое большее, что можетзаметить приложение клиента, — это временное падение производительности.Аналогичным образом большинство распределенных систем реализуют прозрачность репликации на стороне клиента. Представим себе, например, распре-3.3.
Серверы179деленную систему с удаленными объектами. Репликацию удаленного объектаможно осуществить путем рассылки всем репликам запроса, как показано нарис. 3.5. Заместитель клиента в состоянии прозрачно собрать все ответы и передать приложению клиента одно возвращаемое значение.Заместитель размножаетзапросыРеплика 1Реплика 2Реплика 3Все реплики получаютодно и то же обращение^т'Рис. 3.5. Возможный подход к прозрачной репликации удаленных объектовс использованием клиентского программного обеспеченияИ, наконец, обсудим прозрачность к сбоям. Маскирование сбоев во взаимодействрш с серверами обычно выполняется при помощи клиентского программного обеспечения промежуточного уровня.
Так, клиентское программное обеспечение промежуточного уровня можно сконфигурировать таким образом, чтобыоно многократно пыталось связаться с сервером или выбирало после несколькихпопыток другой сервер. Возможна также ситуация, когда программное обеспечение клиента, в случае если web-браузер не в состоянии связаться с сервером, возвращало бы данные, сохраненные в кэше во время предыдущего сеанса связи.Прозрачность параллельного исполнения может обеспечиваться специальными промежуточными серверами, так называемыми мониторами транзакций, и требует меньшей поддержки со стороны клиентского программного обеспечения.Прозрачность сохранности также реализуется серверами.3.3. СерверыДавайте теперь подробнее рассмотрим организацию серверов. На следующихстраницах мы сосредоточимся на некоторых общих вопросах строения серверов,а затем поговорим о серверах объектов.
Серверы объектов имеют большое значение — они формируют строительные блоки для реализации распределенных объектов.3 . 3 . 1 . Общие вопросы разработкиСервер — это процесс, реализующий некоторую службу, требующуюся группеклиентов. Все серверы работают схожим образом: они ожидают входящего сооб-180Глава 3. Процессыидения, посылаемого клиентом, затем проверяют это сообщение на правильность,после чего ожидают следующего сообщения.Серверы могут быть организованы различными способами. В случае итеративного сервера {iterative server) сервер сам обрабатывает запрос и при необходимости возвращает клиенту ответное сообщение. Параллельный сервер (concwrentserver) не обрабатывает сообщение сам, а передает его в отдельный поток выполнения или другой процесс, после чего сразу же переходит в состояние ожиданияследующего входящего сообщения.
Примером параллельного сервера являетсямиогопоточный сервер. В другой реализации параллельного сервера на каждыйпришедший запрос может выделяться новый процесс. Подобный подход применяется во многих UNIX-системах. Поток или процесс, обрабатывающий запрос,отвечает за отправку ответа клиенту, приславшему запрос.Другой момент — каким образом клиент обращается к серверу. Клиент всегдапосылает запросы в конечную точку {endpoint), также именуемую портом {port),той машины, на которой работает сервер.
Каждый сервер просматривает указанную ему конечную точку. Как клиент узнает конечную точку конкретной службы?Одно из решений — глобальное назначение конечных точек широко распространенным службам. Так, серверы, обслуживающие запросы к FTP в Интернете,всегда работают с портом 21. HTTP-серверам World Wide Web всегда назначается TCP-порт 80. Эти конечные точки назначены организацией назначения номеров Интернета (Internet Assigned Numbers Authority, I ANA) и документированыв [379]. Имея назначенные конечные точки, клиенту достаточно знать сетевойадрес той машины, на которой запущена служба.
Как мы увидим в следующейглаве, для этой цели используются службы именования.Существует множество служб, которые не нуждаются в предварительном назначении конечной точки. Так, например, служба времени может использоватьконечную точку, динамически выдаваемую ей локальной операционной системой. В этом случае клиент должен сначала определить конечную точку. Одно изрешений, которое обсуждалось нами для среды DCE, — это создание специального демона, запускаемого на каждой машине, на которой работают серверы. Демон отслеживает текущую конечную точку каждого из серверов, реализуемых наданной машине. Демон сам просматривает общедоступные конечные точки. Припервом контакте с демоном клиент запрашивает конечную точку, после чего связывается с нужным ему сервером, как показано на рис.
3.6, а.Обычно конечная точка ассоциируется с конкретной службой. Однако на самом деле реализация каждой службы отдельным сервером была бы непозволительно щедрым расходованием ресурсов. Так, например, в типичных UNIX-системах нередко имеется множество одновременно работающих серверов, при этомбольшая их часть пассивно ожидает запросов от клиента. Вместо ведения такогомножества пассивных процессов нередко эффективнее иметь один суперсервер{superserver), просматривающий все конечные точки, относящиеся к конкретнымслужбам, как показано на рис. 3.6, б.
Подобный подход реализует, например, демон inetd в UNIX. Этот демон просматривает множество стандартных портовслужб Интернета. В случае прихода запроса он разветвляет процесс и передает3.3. Серверы181запрос на дальнейшую обработку. После окончания обработки дочерний процессзавершается.Машина сервераМашина клиентаРегистрацияконечнойточкиТаблицаконечныхточекмашина клиента 2. Продолжениеработысо службой1.
Запрос службыМашина сервераJJ РеальныйсерверСуперсерверСозданиесерверадля запрашиваемойслужбыРис. 3.6. Привязка клиента к серверу с использованием демона в среде DCE (а).Привязка клиента к серверу с использованием суперсервера в UNIX (б)Еще один момент, который следует принимать во внимание при создании сервера, — когда и как сервер может быть прерван. Для примера рассмотрим пользователя, который решил загрузить на FTP-сервер большой файл. Затем, начавделать это, он обнаружил, что выбрал не тот файл и хотел бы отменить дальнейшую пересылку данных. Существует несколько способов сделать это. Один изподходов, кстати единственный, надежно работающий в современном Интернете(а иногда и единственно возможный), — пользователь немедленно закрываетклиентское приложение (что автоматически вызывает разрыв соединения с сервером), тут же перезапускает его и продолжает работу.
Сервер, естественно, разрывает старое соединение, полагая, что клиент прервал работу.Более правильный способ вызвать прерывание связи — разрабатывать клиенти сервер так, чтобы они могли пересылать друг другу сигнал конца связи {out-ofband), который должен обрабатываться сервером раньше всех прочих передаваемых клиентом данных. Одно из решений — потребовать от сервера просматривать отдельную управляющую конечную точку, на которую клиент будет отправлять сигнал конца связи и одновременно (с более низким приоритетом) —конечную точку, через которую передаются нормальные данные. Другой вариант — пересылать сигнал конца связи через то же соединение, через которое клиент пересылал свой запрос.
В TCP, например, можно посылать срочные данные.182Глава 3. ПроцессыКогда срочные данные достигают сервера, он прерывает свою работу (в UNIXсистемах — по сигналу), после чего может просмотреть эти данные и обработать их.И последний из важных моментов, о которых надо помнить при разработке, — должен или нет сервер хранить информацию о состоянии клиентов.