Представление данных.

Когда клиент и сервер выполняются в одной системе на одном компьютере, проблем с несовместимостью данных не возникает. И для клиента и для сервера данные в двоичном виде представляются одинаково. В случае удаленного вызова дело осложняется тем, что клиент и сервер могут выполняться на системах с различной архитектурой, имеющих различное представление данных (например, представление значения с плавающей точкой, порядок следования байтов и т. д.)

Большинство реализаций системы RPC определяют некоторые стандартные виды представления данных, к которым должны быть преобразованы все значения, передаваемые в запросах и откликах.

Например, формат представления данных в RPC фирмы Sun Microsystems следующий :

Порядок следования байтов Старший - последний

Представление значений с плавающей точкой IEEE

Представление символа ASCII

Сеть.

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

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

- вызываемые процедуры идемпотентны;

- размер передаваемых аргументов и возвращаемого результата меньше размера пакета UDP - 8 Кбайт;

- cервер обеспечивает работу с несколькими сотнями клиентов. Поскольку при работе с протоколами TCP сервер вынужден поддерживать соединение с каждым из активных клиентов, это занимает значительную часть его ресурсов. Протокол UDP в этом отношении является менее ресурсоемким.

С другой стороны, TCP обеспечивает эффективную работу приложений со следующими характеристиками :

- приложению требуется надежный протокол передачи;

- вызываемые процедуры неидемпонентны;

- размер аргументов или возвращаемого результата превышает 8 Кбайт.

Выбор протокола обычно остается за клиентом, и система по-разному организует формирование и передачу сообщений. Так, при использовании протокола TCP, для которого передаваемые данные представляют собой поток байтов, необходимо отделить сообщения друг от друга. Для этого, например, применяется протокол маркировки записей, описанный в RFC1057 "RPC: Remote Procedure Call Protocol specification version 2", при котором в начале каждого сообщения помещается 32-разрядное целое число, определяющее размер сообщения в байтах.

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

Однако даже при использовании надежных транспортных протоколов в случае аварийного завершения работы сервера требуются повторное установление связи (после продолжительного тайм-аута) и повторная передача. В этом случае семантика также меняется.

Принцип работы.

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

E-mail. SMTP.

Электронной почта.

Электронная почта (e-mail) является одним из широко используемым приложением для большинства сетей. До появления Web половина всех устанавливаемых TCP/IP-соединений предназначена для обмена электронной почтой. В этой лекции рассматриваются принципы передачи почтовых сообщений - простой протокол передачи почты (Simple Mail Transfer Protocol, SMTP), а также некоторые дополнительные расширения.

На свете существует множество почтовых программ, клиентов и серверов.

Компоненты электронной почты Интернет.

На рис. 2 приведены настоящие компоненты системы электронной почты, в отличие от концептуальных на рис. 1. Обратите внимание на термины "агент пользователях (user agent, UA) и "агент передачи почты" (message transfer agent, МТА). Как видим, агент пользователя заменяет почтовую программу, а агент передачи почты заменяет процесс-клиент и процесс-сервер.

Рис. 1

Термин "агент" довольно часто встречается в документации Интернет. "Агент" - это программа специального назначения, выполняющая действия для пользователя или другой программы. В большинстве случаев почтовая программа называется агентом пользователя (UA). Точно так же агент передачи почты (МТА) представляет собой клиент или сервер, выполняющий задачи по доставке или получению почты на сетевом компьютере.

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

Рис. 2

В принципе, пользовательский агент отделен от агента передачи почты. Конечно, их можно объединить в одной программе, но все равно это будут отдельные модули. Будучи взаимосвязаны, оба агента выполняют совершенно различные функции. Пользователи системы Unix "со стажем " хорошо знакомы с такими программами, как МН, Berkeley Mail, Elm, Mush и Pine.

Система электронной почты представлена агентами передачи почты, МТА. До того как обсудить задачи пользовательского агента, необходимо узнать немного больше о том, что же такое МТА. МТА умеют устанавливать TCP-соединение для связи с другими МТА. Протоколом этого соединения, как правило, является простой протокол передачи почты (SMTP). В следующем разделе вы познакомитесь с основами SMTP. Этот протокол полностью описан в RFC 821, который так и называется "Простой протокол передачи почты" (Simple Mail Transfer Protocol, Postel, 1982).

Простой протокол передачи почты (SMTP).

Агент передачи почты - основной компонент системы передачи почты Интернет. Как уже говорилось, МТА как бы представляет данный сетевой компьютер для сетевой системы электронной почты. Пользователи редко имеют дело с МТА, поскольку он не вполне "дружелюбен", однако без него не обходится ни одна почтовая система. После того как UA пошлет сообщение в выходную очередь, за дело принимается МТА. Он извлекает сообщение и посылает его другому МТА. Этот процесс продолжается до тех пор, пока сообщение не достигнет компьютера-получателя. Для передачи сообщений по TCP-соединению большинство МТА пользуются протоколом SMTP. Сообщения форматированы по правилам виртуального сетевого терминала (NVT), то есть в NVT ASCII. Как вам известно из десятой главы, NVT подобен виртуальному сетевому протоколу и нужен затем, чтобы скрыть различия в восприятии разными компьютерами разных символов, например переводов каретки, переводов строки, маркеров конца строки, очистки экрана и т. д. Символ в NVT состоит из семи битов набора ASCII и является буквой, цифрой или знаком пунктуации. Семибитный набор ASCII часто называется NVT ASCII.

URL.

Единый указатель ресурсов (англ. URL — Uniform Resource Locator) — единообразный локатор (определитель местонахождения) ресурса. По-английски «URL» целиком произносится как /ɜː(ɹ)l/, по-русски чаще говорят. Ранее назывался Universal Resource Locator — универсальный локатор ресурса. URL — это стандартизированный способ записи адреса ресурса в сети Интернет.

Структура URL

Изначально локатор URL был разработан как система для максимально естественного указания на местонахождения ресурсов в сети. Локатор должен был быть легко расширяемым и использовать лишь ограниченный набор ASCII‐символов (к примеру, пробел никогда не применяется в URL).

Кодирование URL

Появление адресов URL стало существенным нововведением в Интернете. Однако с момента его изобретения и по сей день стандарт URL обладает серьёзным недостатком — в нём можно использовать только ограниченный набор символов, даже меньший, нежели в ASCII: латинские буквы, цифры и лишь некоторые знаки препинания. Если мы захотим использовать в URL символы кириллицы, или иероглифы, или, скажем, специфические символы французского языка, то нужные нам символы должны быть перекодированы особым образом.

Инициатива PURL

Ещё один кардинальный недостаток URL состоит в отсутствии гибкости. Ресурсы во Всемирной паутине и Интернете перемещаются, а ссылки в виде URL остаются, указывая на уже отсутствующие ресурсы. Это особенно болезненно для электронных библиотек, каталогов и энциклопедий. Для решения этой проблемы были предложены постоянные локаторы PURL (англ. Persistent Uniform Resource Locator). В сущности это те же URL, но они указывают не на конкретное место расположения ресурса, а на запись в базе данных PURL, где, в свою очередь, записан уже конкретный URL‐адрес ресурса. При обращении к PURL сервер находит нужную запись в этой базе данных и перенаправляет запрос уже на конкретное местоположение ресурса. Если адрес ресурса меняется, то нет нужды исправлять все бесчисленные ссылки на него — достаточно лишь изменить запись в БД. В настоящий момент эта идея не стандартизирована и не имеет широкого распространения.

Web сервер. HTTP.

Web-сервер - программа, которая "слушает" сеть (обычно 80 порт), принимает сообщения и реагирует на них, посылая в ответ домашнюю страницу своей организации. При этом к Web-серверу предъявляются следующие требования :

- он должен : работать быстро, чтобы справляться со множеством запросов, используя минимум аппаратных средств;

- быть многозадачным, т.е. работать одновременно с множеством запросов; а еще раз быть многозадачным, чтобы человек, управляющий им, мог осуществлять сопровождение выдаваемых сервером данных, не завершая его работы. Для этого необходимо запускать сервер в многозадачной операционной системе (UNIX, Windows NT, OS/2); а иметь средства аутентификации запрашивающих абонентов: некоторые из них могут иметь право на большее число услуг, чем другие;

- реагировать на ошибки в получаемых сообщениях ответами, которые имеют смысл в контексте происходящего. Например, если клиент запрашивает страницу, которую сервер не может найти, последний должен выдать в ответ сообщение об ошибке "404", смысл которого в спецификации HTTP определяется как "страница не существует"

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

- предлагать разные форматы. Говоря техническим языком, пользователю могут понадобиться файлы в формате JPEG, а не GIF, или не то и не другое, а TIFF. Может ему захочется посмотреть текст не в формате PostScript, а в формате vdi;

- работать как proxy-сервер. Proxy-сервер - это сервер, который принимает запросы от клиентов и пересылает их на реальные серверы, а затем передает ответы от этих серверов обратно клиентам. Необходимость этого объясняется двумя причинами:

- proxy-сервер может работать на внешней стороне брандмауэра, предоставляя своим пользователям доступ к Internet;

- он может кэшировать популярные страницы, обеспечивая повторный доступ к ним;

- быть надежным.

Технология клиент-сервер. HTTP протокол.

Hypertext Transfer Protocol (HTTP, протокол пересылки гипертекста)-это язык, которым клиенты и серверы World Wide Web пользуются для общения между собой. Он по сути дела и является основой в Web.

Хотя HTTP в большей мере относится к сфере программирования серверов и клиентов, знание этого протокола важно и для С01-программирования[2]. Кроме того, иногда HTTP фильтрует информацию и передает ее обратно пользователям - это происходит, например, когда в окне браузера отображаются коды ошибок сервера. На следующем рисунке приводится модель взаимодействия клиент-сервер с помощью протокола http.