темами Теоретической основой сетевого взаимодействия удаленных систем является общеизвестная модель взаим
Работа добавлена на сайт samzan.net:
Понятие промежуточной среды
С точки зрения одного из компьютеров распределенной системы, все другие входящие в нее машины являются удаленными вычислительными системами. Теоретической основой сетевого взаимодействия удаленных систем является общеизвестная модель взаимодействия открытых систем OSI/ISO, которая разделяет процесс взаимодействия двух сторон на семь уровней: физический, канальный, сетевой, транспортный, сеансовый, прикладной, представительский.
Рис. 1.9. Модель взаимодействия вычислительных систем
Сетевая модель OSI
Представляет уровневый подход к сети. Каждый уровень обслуживает свою часть процесса взаимодействия. Благодаря такой структуре совместная работа сетевого оборудования и программного обеспечения становится гораздо проще и понятнее.
Разумеется, в настоящее время основным используемым семейством протоколов является TCP/IP, разработка которого не была связана с моделью OSI. За все время существования модели OSI она не была реализована, и, по-видимому, не будет реализована никогда. Сегодня используется только некоторое подмножество модели OSI. Считается, что модель слишком сложна, а её реализация займёт слишком много времени.
Прикладной уровень (Application layer)
Верхний (7-й) уровень модели, обеспечивает взаимодействие сети и пользователя. Уровень разрешает приложениям пользователя доступ к сетевым службам, таким как обработчик запросов к базам данных, доступ к файлам, пересылке электронной почты. Также отвечает за передачу служебной информации, предоставляет приложениям информацию об ошибках и формирует запросы к уровню представления.
Уровень представления (Presentation layer)
Этот уровень отвечает за преобразование протоколов и кодирование/декодирование данных. Запросы приложений, полученные с уровня приложений, он преобразует в формат для передачи по сети, а полученные из сети данные преобразует в формат, понятный приложениям. На этом уровне может осуществляться сжатие/распаковка или кодирование/декодирование данных, а также перенаправление запросов другому сетевому ресурсу, если они не могут быть обработаны локально.
Сеансовый уровень (Session layer)
Отвечает за поддержание сеанса связи, позволяя приложениям взаимодействовать между собой длительное время. Уровень управляет созданием/завершением сеанса, обменом информацией, синхронизацией задач, определением права на передачу данных и поддержанием сеанса в периоды неактивности приложений. Синхронизация передачи обеспечивается помещением в поток данных контрольных точек, начиная с которых возобновляется процесс при нарушении взаимодействия
Транспортный уровень (Transport layer)
4-й уровень модели, предназначен для доставки данных без ошибок, потерь и дублирования в той последовательности, как они были переданы. При этом неважно, какие данные передаются, откуда и куда, то есть он предоставляет сам механизм передачи. Блоки данных он разделяет на фрагменты, размер которых зависит от протокола, короткие объединяет в один, а длинные разбивает. Протоколы этого уровня предназначены для взаимодействия типа точка-точка.
Сетевой уровень (Network layer)
3-й уровень сетевой модели OSI, предназначен для определения пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, определение кратчайших маршрутов, коммутацию и маршрутизацию, отслеживание неполадок и заторов в сети. На этом уровне работает такое сетевое устройство, как маршрутизатор.
Канальный уровень (Data Link layer)
Этот уровень предназначен для обеспечения взаимодействия сетей на физическом уровне и контроля за ошибками, которые могут возникнуть. Полученные с физического уровня данные он упаковывает в кадры данных, проверяет на целостность, если нужно исправляет ошибки и отправляет на сетевой уровень. Канальный уровень может взаимодействовать с одним или несколькими физическими уровнями, контролируя и управляя этим взаимодействием. Спецификация IEEE 802 разделяет этот уровень на 2 подуровня — MAC (Media Access Control) регулирует доступ к разделяемой физической среде, LLC (Logical Link Control) обеспечивает обслуживание сетевого уровня. На этом уровне работают коммутаторы, мосты.
В программировании этот уровень представляет драйвер сетевой платы, в операционных системах имеется программный интерфейс взаимодействия канального и сетевого уровня между собой, это не новый уровень, а просто реализация модели для конкретной ОС. Примеры таких интерфейсов: ODI, NDIS.
Физический уровень (Physical layer)
Самый нижний уровень модели, предназначен непосредственно для передачи потока данных. Осуществляет передачу электрических или оптических сигналов в кабель и соответственно их приём и преобразование в биты данных в соответствии с методами кодирования цифровых сигналов. Другими словами, осуществляет интерфейс между сетевым носителем и сетевым устройством. На этом уровне работают концентраторы, повторители (ретрансляторы) сигнала и медиа конверторы.
Взаимодействие уровней
Уровни взаимодействуют сверху вниз и снизу вверх посредством интерфейсов и могут еще взаимодействовать с таким же уровнем другой системы с помощью протоколов. Подробнее можно посмотреть на рисунке.
В сетях наиболее распространенного стека протоколов TCP/IP протокол TCP является протоколом транспортного, а протокол IP – протоколом сетевого уровня. Обеспечение интерфейса к транспортному уровню в настоящее время берет на себя сетевая компонента операционной системы, предоставляя обычно основанный на сокетах интерфейс для верхних уровней. Сокеты обеспечивают примитивы низкого уровня для непосредственного обмена потоком байт между двумя процессами. Стандартного представительского или сеансового уровня в стеке протоколов TCP/IP нет, иногда к ним относят защищенные протоколы SSL/TLS.
Использование протокола TCP/IP посредством сокетов предоставляет стандартный, межплатформенный, но низкоуровневый сервис для обмена данными между компонентами. Для выполнения сформулированных выше требований к распределенным системам функции сеансового и представительского уровня должна взять на себя некоторая промежуточная среда (middleware), называемая так же промежуточным программным обеспечением (рис. 1.9). Такая среда должна помочь создать разработчиками открытые, масштабируемые и устойчивые распределенные системы. Для достижения этой цели промежуточная среда должна обеспечить сервисы для взаимодействия компонент распределенной системы. К таким сервисам относятся:
- обеспечение единого и независимого от операционной системы механизма использования одними программными компонентами сервисов других компонент;
- обеспечение безопасности распределенной системы: аутентификация и авторизация всех пользователей сервисов компоненты и защита передаваемой между компонентами информации от искажения и чтения третьими сторонами;
- обеспечение целостности данных: управление транзакциями, распределенными между удаленными компонентами системами;
- балансировка нагрузки на серверы с программными компонентами;
- обнаружение удаленных компонент.
В пределах одной распределенной системы может использоваться несколько видов промежуточных сред (рис. 1.10). При хорошем подходе к проектированию системы каждая распределенная ее компонента предоставляет свои сервисы посредством единственной промежуточной среды, и использует сервисы других компонент посредством так же единственной промежуточной среды, однако эти среды могут быть различными.
Рис. 1.10. Гетерогенная распределенная система
Распределенную систему, компоненты которой используют несколько промежуточных сред, можно называть гетерогенной, в противоположность гомогенной, использующей единственную промежуточную среду. Поскольку одна и та же промежуточная среда может быть реализована на различных аппаратных платформах и операционных системах, то оба класса распределенных систем могут включать в себя компьютеры под управлением как одной, так и различных операционных систем.
В настоящий момент нет универсально применимой промежуточной среды, хотя как будет показано в курсе, есть определенное движение в этом направлении. Основной причиной отсутствия такой среды являются отчасти противоречивые требования к распределенным системам, а так же различающийся характер сетевых соединений между компонентами системы: например взаимодействие компонент внутри одного предприятия, вероятно, может быть построено иначе, чем взаимодействие компонент двух различных предприятий, не полностью доверяющих друг другу.
Взаимодействие программных компонент в пределах одного и того же компьютера также происходит при помощи промежуточной среды, что при использовании некоторых промежуточных сред может быть как неудобно, так и неэффективно. В идеальном случае распределенная компонента должна быть реализована таким образом, чтобы переход с одной промежуточной среды на другую происходил путем изменения конфигурации программной компоненты, а не изменения исходного кода. На практике данное требование, к сожалению, может быть трудно осуществимо, однако необходимо хотя бы минимизировать возможные исправления программного кода при возможной смене промежуточной среды.
Протоколы прикладного уровня
2 класса: жесткие и гибкие.
Протокол = формат передаваемых данных + алгоритм.
Эта классификация осуществляется с т.з. структуры данных, которыми обмениваются клиент и сервер.
[заголовок][блок данных]
Жесткий протокол проще для реализации, требует меньше накладных расходов.
При использовании жесткого протокола структура данных не меняется.
«+»: разбор данных и упаковку делать не надо => быстрота выполнения и сервера, и клиента
«-»: для разных функций блок данных разный
Заголовок: размер блока, сервер, функция, идентификатор клиента, код завершения
Заголовок может быть универсальным, тогда нужен код завершения.
Гибкий протокол является универсальным, но в КМ добавляется упаковка/распаковка + анализ.
Заголовок = то же + количество параметров, упакованных в блок данных. При упаковке каждый параметр, упакованный в блок, сопровождается своим заголовком (тип и размер + может быть имя)
Модели взаимодействия компонент распределенной системы
Ключевым сервисом промежуточной среды для создания распределенных систем является обеспечение обмена данными между компонентами распределенной системы. В настоящий момент существуют две концепции взаимодействия программных компонент: обмен сообщениями между компонентами и вызов процедур или методов объекта удаленной компоненты по аналогии с локальным вызовом процедуры. Поскольку в настоящее время любое взаимодействие между удаленными компонентами в конечном итоге основано на сокетах TCP/IP, первичным с точки зрения промежуточной среды является низкоуровневый обмен сообщениями на основе сетевых сокетов, сервис которых никак не определяет формат передаваемого сообщения. На базе протоколов TCP или HTTP затем могут быть построены прикладные протоколы обмена сообщений более высокого уровня абстракции для реализации более сложного обмена сообщениями или удаленного вызова процедур.
Удаленный вызов является моделью, происходящей от языков программирования высокого уровня, а не от реализации интерфейса транспортного уровня сетевых протоколов. Поэтому протоколы удаленного вызова должны обязательно базироваться на какой либо системе передачи сообщений, включая как непосредственное использование сокетов TCP/IP, так и основанные на нем другие промежуточные среды для обмена сообщениями. Реализация высокоуровневых служб обмена сообщениями, в свою очередь, может использовать удаленный вызов процедур, основанный на более низкоуровневой передаче сообщений, использующей, например, непосредственно сетевые сокеты. Таким образом, одна промежуточная среда может использовать для своего функционирования сервисы другой промежуточной среды, аналогично тому, как один протокол транспортного или сетевого уровня может работать поверх другого протокола при туннелировании протоколов.
Обмен сообщениями
Существует два метода передачи сообщений от одной удаленной системы к другой – непосредственный обмен сообщениями и использование очередей сообщений. В первом случае передача происходит напрямую, и она возможна только в том случае, если принимающая сторона готова принять сообщение в этот же момент времени. Во втором случае используется посредник – менеджер очередей сообщений. Компонента посылает сообщение в одну из очередей менеджера, после чего она может продолжить свою работу. В дальнейшем получающая сторона извлечет сообщение из очереди менеджера и приступит к его обработке.
Простейшей реализацией непосредственного обмена сообщениями является использование транспортного уровня сети через интерфейс сокетов, минуя какое-либо промежуточное программное обеспечение. Однако такой способ взаимодействия обычно не применяется в системах автоматизации предприятия, поскольку в этом случае реализация всех функций промежуточной среды ложится на разработчиков приложения. При таком подходе сложно получить расширяемую и надежную распределенную систему, поэтому для разработки прикладных распределенных систем обычно используются системы очередей сообщений.
Существует несколько разработок в области промежуточного программного обеспечения, реализующие высокоуровневые сервисы для обмена сообщениями между программными компонентами. К ним относятся, в частности, Microsoft Message Queuing, IBM MQSeries и Sun Java System Message Queue. Такие системы дают возможность приложениям использовать следующие базовые примитивы по использованию очередей:
- добавить сообщение в очередь;
- взять первое сообщение из очереди, процесс блокируется до появления в очереди хотя бы одного сообщения;
- проверить очередь на наличие сообщений;
- установить обработчик, вызываемый при появлении сообщений в очереди.
Менеджер очереди сообщений в таких системах может находиться на компьютере, отличном от компьютеров с участвующими в обмене компонентами. В этом случае сообщение первоначально помещается в исходящую очередь на компьютере с посылающей сообщения компонентой, а затем пересылается менеджеру требуемой. Для создания крупных систем обмена сообщениями может использоваться маршрутизация сообщений, при которой сообщения не передаются напрямую менеджеру, поддерживающему очередь, а проходят через ряд промежуточных менеджеров очередей сообщений (рис. 2.1).
Рис. 2.1. Системы очередей сообщений
Использование очередей сообщений ориентировано на асинхронный обмен данными. Основные достоинства таких систем:
- время функционирования сервера может быть не связано со временем работы клиентов;
- независимость промежуточной среды от средства разработки компонент и используемого языка программирования;
- считывать и обрабатывать заявки из очереди могут несколько независимых компонент, что дает возможность достаточно просто создавать устойчивые и масштабируемые системы.
Недостатки систем очередей сообщений являются продолжением их достоинств:
- необходимость явного использования очередей распределенным приложением;
- сложность реализации синхронного обмена;
- определенные накладные расходы на использование менеджеров очередей;
- сложность получения ответа: передача ответа может потребовать отдельной очереди на каждый компонент, посылающий заявки.
Дальний вызов процедур
Идея удаленного вызова процедур (remote procedure call, RPC) появилась в середине 80-х годов и заключалась в том, что при помощи промежуточного программного обеспечения функцию на удаленном компьютере можно вызывать так же, как и функцию на локальном компьютере. Чтобы удаленный вызов происходил прозрачно с точки зрения вызывающего приложения, промежуточная среда должна предоставить процедуру-заглушку (stub), которая будет вызываться клиентским приложением. После вызова процедуры-заглушки промежуточная среда преобразует переданные ей аргументы в вид, пригодный для передачи по транспортному протоколу, и передает их на удаленный компьютер с вызываемой функцией. На удаленном компьютере параметры извлекаются промежуточной средой из сообщения транспортного уровня и передаются вызываемой функции (рис. 2.2). Аналогичным образом на клиентскую машину передается результат выполнения вызванной функции.
Рис. 2.2. Удаленный вызов процедур
Существует три возможных варианта удаленного вызова процедур.
- Синхронный вызов: клиент ожидает завершения процедуры сервером и при необходимости получает от него результат выполнения удаленной функции;
- Однонаправленный асинхронный вызов: клиент продолжает свое выполнение, получение ответа от сервера либо отсутствует, либо его реализация возложена на разработчика (например, через функцию клиента, удалено вызываемую сервером).
- Асинхронный вызов: клиент продолжает свое выполнение, при завершении сервером выполнения процедуры он получает уведомление и результат ее выполнения, например через callback-функцию, вызываемую промежуточной средой при получении результата от сервера.
Процесс преобразования параметров для передачи их между процессами (или доменами приложения в случае использования .NET) при удаленном вызове называется маршализацией (marshalling). Преобразование экземпляра какого-либо типа данных в пригодный для передачи за границы вызывающего процесса набор байт называется сериализацией. Десериализация – процедура, обратная сериализации – заключается в создании копии сериализованного объекта на основе полученного набора байт. Такой подход к передаче объекта между процессами путем создания его копий называется маршализацией по значению (marshal by value), в отличие от рассматриваемой в следующем разделе маршализации по ссылке.
Процесс сериализации должен быть определен для всех типов данных, передаваемых при удаленном вызове. К ним относятся параметры вызываемой функции и возвращаемый функцией результат. В случае передачи параметров по ссылке сериализации подлежат ссылаемые объекты, поскольку для самих указателей сериализация не может быть применена. Это затрудняет использование механизма удаленного вызова в языках, поддерживающих указатели на объекты неизвестного типа.
2. Наука и религия, формирование русского государства и развитие естественнонаучных знаний
3. В нашей стране разработка проблемы эволюции сообществ связана с такими именами как В
4. д 2 Оценить состояние пострадавшего определить характер и тяжесть травмы наибольшую угрозу для жизни по
5. Тема- Concordnce des temps Практическая цель- совершенствование лексикограмматических навыков
6. Русским Рязань татарам Казань
7. Курсовая работа- Стан та напрями удосконалення первинного обліку оплати праці
8. а К О М М Е Р Ч Е С К О Е П Р Е Д Л О Ж Е Н И Е Мы работаем в сфере производства и реализации рабочих перча
9. Mking secret in history ПОСВЯЩЕНИЕ Введение СИЛА ОТДАЧИ Джон Хэрричаран ВЕЛИЧАЙШИЙ В ИСТОРИИ СЕКРЕТ ТОГО КАК Д
10. і ~азіргі та~да университет Республикада~ы жетекші о~у орны
11. акции и силой раздражителя вызывающего условный рефлекс
12. Воспрепятствование законной предпринимательской деятельности
13. Родничок Солнышка сынок родной ~ одуванчик золотой
14. Задание 93 Обозначение звена Нормал
15. Психология народов и масс Если трудно внушать новую идею то не менее трудно уничтожить старую.html
16. Строение глаза 5 2
17. Реферат Стабилитроны
18. Курсовая работа- Восстановление базы данных
19. БИлер ке~есіні~ м~шесі ата~ты шешен ~лы ж~зді~ т~бе биі Жеті жар~ы деп аталатын за~дар кодексін шы~ару
20. тема эргатические функции