Добавлен: 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 передает сообщение по сети клиентскому стабу, а тот возвращает обычным образом результат и управление вызывающей процедуре. Ни вызывающая процедура, ни оригинальная вызываемая процедура не изменились оттого, что они стали работать на разных компьютерах.