Файл: Понятие и принципы построения серверных программ.pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 26.06.2023

Просмотров: 74

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

В качестве элемента информации (ресурса), который делается доступным для запроса пользователем, может выступать любой файл, находящийся в информационном массиве Web-сервера. Так же с помощью протокола HTTP возможен удаленный запуск приложений на Web-сервере. Эта возможность реализуется с помощью технологииCGI.

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

Адресация сетевых ресурсов в Интернет осуществляется с помощью указателей URL(Uniform Resource Locator). Для Web большинство URL в общем виде имеет следующий формат:

>,

где <хост>- доменное имя или IP-адрес компьютера-сервера,<порт>- IP-порт для соединения (если пропущено - используется порт по умолчанию - 80),<путь>- указывает расположение ресурса в структуре Web-сервера (часто совпадает с подкаталогом и именем файла в файловой системе сервера),<параметры>- используется для передачи параметров исполняемым сценариям (может отсутствовать).

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

Для передачи информации от пользователя к серверу язык HTML позволяет строить так называемые формы. Формы могут состоять из целого ряда интерфейсных управляемых элементов - списков выбора, из которых пользователь может выбрать одно или несколько значений, текстовых полей для ввода многострочных фрагментов текста, переключателей, предназначенных для выбора одного или нескольких вариантов из набора имеющихся, полей для ввода строк текста и других элементов. Каждый такой элемент имеет имя. Обязательным элементом формы является параметрaction, указывающий на Web-документ (обычно - CGI- или PHP-сценарий), вызываемый по окончании работы с формой - по завершении ввода данных или редактирования значений, а так же кнопка, при нажатии на которую на Web-сервере вызывается этот сценарий. В качестве параметров этому сценарию передаются парыимя_элемента=значение, формируемые для каждого интерфейсного элемента формы [4]. После обработки полученных данных сценарий выполняет заданные действия, а результат его работы передается пользователю.

Таким образом, передача пользовательской информации на Web-сервер с помощью HTML-формы производится как минимум в два этапа – на первом этапе выполняется заполнение формы, представляющей собой отдельный Web-документ, на втором этапе – выполняется передача информации на сервер сценарию, который будет обрабатывать ее.


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

Таким образом, при применении Web-сервера на базе ОС Unix для реализации интерактивных Web-документов на стороне сервера предпочтительным является использование языка PHP. В случае повышенных требований к быстродействию при обработке больших объемов информации рекомендуется использование интерфейса CGI со сценариями, написанными на компилируемых языках. На серверах на базе Windows предпочтительно применение технологии ASP. Для проверки больших объемов информации перед передачей их на сервер или для реализации обработки информации на стороне пользователя рекомендуется использовать компоненты DHTML.

Выбор оптимального с точки зрения быстродействия решения возможен лишь при сравнении нескольких способов решения одной задачи с применением различных технологий. 

Глава 2. Применение дистанционных вызовов процедур для построения программ, функционирующих по принципу клиент/сервер

Фирма Sun Microsystems построила NFS на базе концепции RPC (Remote Procedure Calls Дистанционный вызов процедур), которая позволяет программному обеспечению на разных машинах связываться между собой. Эта концепция состоит в том, что отдельные модули программного обеспечения, выполняющие разные функции, располагаются на компьютерах различных типов. Система NFS использует RPC для перенаправления файлов в компьютерной сети.

Дистанционный вызов процедур (RPC) выполняет роль магического клея, который программистам склеивать разнородные компьютеры в сети так, что они ведут себя как один большой компьютер. С применением этой системы отдельные части прикладной программы можно запускать на тех компьютерах вычислительной сети, которые наилучшим образом приспособлены для этого. RPC является прекрасным инструментом для построения систем клиент/сервер.

Что же программист должен делать, чтобы использовать RPC? Для этого он программирует отдельные модули, обычно на языке программирования С. каждый модуль предназначен для выполнения функции клиента или сервера. Модули сервера, как правило, являются программами заднего плана (вычисления, создание отчетов ил хранение временных записей базы данных), а модули клиента выполняются функции переднего плана (интерфейс пользователя). Затем составляется сценарий для RPC компилятора, где указываются модули-клиенты и модули-серверы. RPC компилятор генерирует Си-программу для склеивания отдельных модулей в единую систему, в рамках которой осуществляются сеансы связи между клиентами и серверами, расположенными на различных компьютерах. При этом, с точки зрения программистов, вызов модулей сервера осуществляется точно так же, как и любых других программ в программе клиента. то, что модули клиента и сервера находятся на различных компьютерах, остается совершенно невидимым для прикладной программы.


Компьютеры, составляющие сеть NFS, могут быть самых различных моделей и использовать совершенно различные способы внутреннего представления данных. Для учета этих различий в NFS применяется протокол XDR (External Data Representation Внешнее представление данных). С помощью этого протокола информация в пакетах сообщений преобразовывается в машинонезависимый формат.

В системе NFS клиенты и серверы не запоминают состояние предыдущих операций с файлами. В этом смысле этот протокол является независимым от предыстории. Это можно пояснить на следующем примере. Рабочая станция посылает запрос на NFS-сервер с требованием открыть файл для чтения и получает ответ «файл открыт». Позже, когда рабочей станции потребуется прочитать данные из этого файла, она должна послать запрос чтения данных. Этот запрос вместе с именем файла должен также содержать и текущее положение указателя файла. Таким образом, на сервере нет необходимости помнить о состоянии предыдущей операции с файлами. Вследствие этого NFS оказывается более медленной операционной системой, чем другие. Замедление работы является результатом большего графика из-за больших пакетов (каждый из них переносит всю необходимую информацию по его обработке) и большего времени на обработку пакета.

Независимость от предыстории NFS позволяет избежать сложных процедур восстановления при сбоях в обмене данными между элементами клиента и сервера. В таких ситуациях клиент просто продолжает отправлять заново запросы к серверу до тех пор, пока не получит нужные ему данные. Фактически, клиент не видит разницы между медленным сервером и сервером, в котором произошел сбой. Аналогично, после перезапуска сервер продолжает, как ни в чем не бывало, отвечать на запросы клиентов без необходимости перезапуска каждого из клиентов. В NFS используется описанный выше протокол UDP (User Datagram Protocol Протокол пользовательских дата-грамм) для передачи/приема требований обслуживания файлов.

Идея вызова удаленных процедур состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выпол­няющейся на одной машине, на передачу управления и данных через сеть. Сред­ства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений. Впервые механизм RPC реализовала компания Sun Microsystems, и он хорошо соответствует девизу «Сеть — это компьютер», взято­му этой компанией на вооружение, так как приближает сетевое программирование к локальному. Наибольшая эффективность RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем ответов и относительно малым количеством передаваемыхданных. Такие приложения называются RFC-ориентированными.


Характерными чертами вызова локальных процедур являются:

- асимметричность — одна из взаимодействующих сторон является инициато­ром взаимодействия;

- синхронность — выполнение вызывающей процедуры блокируется с момента выдачи запроса и возобновляется только после возврата из вызываемой про­цедуры.

Реализация удаленных вызовов существенно сложнее реализации вызовов локаль­ных процедур. Начнем с того, что поскольку вызывающая и вызываемая процеду­ры выполняются на разных машинах, то они имеют разные адресные простран­ства и это создает проблемы при передаче параметров и результатов, особенно если машины и их операционные системы не идентичны. Так как RPC не может рассчитывать на разделяемую память, это означает, что параметры RPC не долж­ны содержать указателей на ячейки памяти и что значения параметров должны как-то копироваться с одного компьютера на другой.

Следующим отличием RPC от локального вызова является то, что он обязатель­но использует нижележащую систему обмена сообщениями, однако это не долж­но быть явно видно ни в определении процедур, ни в самих процедурах. Удален­ность вносит дополнительные проблемы. Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках еди­ного процесса. Но в реализации RPC участвуют как минимум два процесса — по одному и каждой машине. В случае если один из них аварийно завершится, мо­гут возникнуть следующие ситуации:

- при аварии вызывающей процедуры, удаленно вызванные процедуры стано­вятся «осиротевшими»;

- при аварийном завершении удаленных процедур становятся «обездоленными родителями» вызывающие процедуры, которые будут безрезультатно ожи­дать ответа от удаленных процедур.

Кроме того, существует ряд проблем, связанных с неоднородностью языков про­граммирования и операционных сред: структуры данных и структуры вызова про­цедур, поддерживаемые в каком-либо одном языке программирования, не под­держиваются точно таким же способом в других языках.

Рассмотрим, каким образом технология RPC, лежащая в основе многих распре­деленных операционных систем, решает эти проблемы.

Чтобы понять работу RPC, рассмотрим сначала выполнение вызова локальной процедуры в автономном компьютере. Пусть это, например, будет процедура за­писи данных в файл:

m = my_write(fd, but, length)

Здесь fd — дескриптор файла, целое число, buf — указатель на массив символов, length— длина массива, целое число.

Чтобы осуществить вызов, вызывающая процедура помещает указанные пара­метры в стек в обратном порядке и передает управление вызываемой процедуреmy_write. Эта пользовательская процедура после некоторых манипуляций с дан­ными символьного массива buf выполняет системный вызов write для записи дан­ных в файл, передавая ему параметры тем же способом, то есть, помещая их в стек (при реализации системного вызова они копируются в стек системы, а при возврате из него результат помещается в пользовательский стек). После того как процедура my_write выполнена, она помещает возвращаемое значение m в регистр, перемещает адрес возврата и возвращает управление вызывающей процедуре, кото­рая выбирает параметры из стека, возвращая его в исходное состояние. Заметим, что в языке C параметры могут вызываться по ссылке (by name), представляю­щей собой адрес глобальной области памяти, в которой хранится параметр, или по значению (byvalue), в этом случае параметр копируется из исходной области памяти в локальную память процедуры, располагаемую обычно в стековом сег­менте. В первом случае вызываемая процедура работает с оригинальными значе­ниями параметров и их изменения сразу же видны вызывающей процедуре. Во втором случае вызываемая процедура работает с копиями значений параметров, и их изменения никак не влияют на значение оригиналов этих переменных в вы­зывающей процедуре. Эти обстоятельства весьма существенны для RPC.


Решение о том, какой механизм передачи параметров использовать, принима­ется разработчиками языка. Иногда это зависит от типа передаваемых данных. В языке C, например, целые и другие скалярные данные всегда передаются по значению, а массивы — по ссылке.

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

Механизм RPC достигает прозрачности следующим образом. Когда вызываемая процедура действительно является удаленной, в библиотеку процедур вместо локальной реализации оригинального кода процедуры помещается другая вер­ сия процедуры, называемая клиентским стабом (stub — заглушка). На удаленный компьютер, который выполняет роль сервера процедур, помещается оригиналь­ный код вызываемой процедуры, а также еще один стаб, называемый серверным стабом. Назначение клиентского и серверного стабов – организовать передачу параметров вызываемой процедуры и возврат значения процедуры через сети, при этом код оригинальной процедуры, помещенной на сервер, должен быть полностью сохранен. Стабы используют для передачи данных через сеть средства подсистемы обмена сообщениями, то есть существующие в ОС примитивы send иreceive. Иногда в подсистеме обмена сообщениями выделяется программный модуль, организующий связь стабов с примитивами передачи сообщений, называемый модулем RPCRuntime.

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

Эта операция называется операцией упаковки параметров. После этого клиент­ский стаб обращается к примитиву send для передачи этого сообщения удаленно­му компьютеру, на который помещена реализация оригинальной процедуры. По­лучив из сети сообщение, ядро ОС удаленного компьютера вызывает серверный стаб, который извлекает из сообщения параметры и вызывает обычным образом оригинальную процедуру. Для получения сообщения серверный стаб должен предварительно вызвать примитив receive, чтобы ядро знало, для кого пришло сообщение. Серверный стаб распаковывает параметры вызова, имеющиеся в со­общении, и обычным образом вызывает оригинальную процедуру, передавая ей параметры через стек. После окончания работы процедуры серверный стаб упа­ковывает результат ее работы в новое сообщение и с помощью примитива send передает сообщение по сети клиентскому стабу, а тот возвращает обычным обра­зом результат и управление вызывающей процедуре. Ни вызывающая процеду­ра, ни оригинальная вызываемая процедура не изменились оттого, что они ста­ли работать на разных компьютерах.