Эскорт-услуги в Москве от Queens Palace


GOUSPO студенческий портал!

форум, учебники, лекции, и многое другое

Мар

31

Инструментальные средства создания клиентской части

Автор: admin

Инструментальные  средства создания клиентской части

1. Опорная модель OSI

В общем случае задача сетевого программного обеспечения состоит в приеме запроса (обычно это запрос ввода-вывода) от приложения на одной машине, передаче его на другую машину, выполнения запроса на удаленной машине и возврате результата на первую машину. В ходе этих операций за­прос несколько раз преобразуется. Высокоуровневый запрос (например, прочитать N байтов из файла Xна машине Y) требует, чтобы программное обеспечение определило, как достичь машины Y и какой коммуникационный протокол она понимает. Затем запрос должен быть преобразован для пере­дачи по сети например, разбит на короткие пакеты информации. Когда за­прос достигнет другой стороны, необходимо проверить его целостность, де­кодировать и послать на выполнение соответствующему компоненту ОС. По окончании выполнения запрос должен быть декодирован для обратной пере­дачи по сети.

Для помощи производителям в стандартизации и интегрировании про­изводимого сетевого ПО, Международная организация по стандартизации (ISO, International Standart Organization) в 1984 году определила программ­ную модель пересылки сообщений между компьютерами. Эта модель полу­чила название опорной модели соединения открытых систем Open Systems Interconnection (OSI) referencemodel. В модели OSI определены семь уровней программного обеспечения.

Опорная модель OSI - идеальная схема, точно реализованная на очень немногих системах, однако она часто используется при обсуждении основ­ных принципов работы сетей. Каждый уровень одной из машин считает, что он разговаривает на одном и том же языке (или протоколе) с соответст­вующем уровнем другой ЭВМ (т.н. виртуальные связи между уровнями). Однако в действительности сетевой запрос должен спуститься до самого нижнего (физического) уровня (на ко­тором обе ЭВМ в реальности обмениваются данными), затем он передается по физическому носителю и вновь поднимается до уровня, который его поймет и обработает. Набор протоколов, в соответствие с которым запрос проходит вниз по уровням сети и обратно, называется стеком протоколов (protocol stack). Каждый уровень несет ответственность за выполнение огра­ниченного набора функций и может взаимодействовать только с двумя непо­средственно прилежащими уровнями.

Задача каждого уровня состоит в предоставлении обслуживания верх­ним уровням, абстрагируясь от того, каким образомреализовано это об­служивание.

Краткое описание  уровней модели OSI.

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

•  Уровень представления. Отвечает за формирование данных (в том числе решает, должны ли строки заканчиваться парой символов возврат ка­ретки/перевод строки - CR/LF) или только символом возврат каретки - CR; должны ли данные быть сжаты или закодированы и др.

•  Сеансовый уровень. Управляет соединением между взаимодействую­щими приложениями (включая синхронизацию высокого уровня и кон­троль за тем, какое из приложений говорит, а какое слушает).

•  Транспортный уровень. Осуществляет разбивку сообщения на пакеты и присваивает номера пакетам, чтобы гарантировать их прием в надлежа­щем порядке. Кроме того, изолирует сеансовый уровень влияния аппа­ратных изменений.

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

•  Канальный уровень. Пересылает низкоуровневые кадры данных, ожида­ет подтверждения их получения и повторяет передачу кадров, потерян­ных в ненадежных линиях связи.

•  Физический уровень. Передает (и принимает) биты по сетевому кабелю (или другой физической передающей среде).

Уровни 1 и 2 (физический и канальный) являются уровнями аппаратных средству уровни 3, 4, 5 образуют подсетевой уровень сети, который содер­жит программные средства, управляющие аппаратными средствами сети. Подсетевой уровень определяет один из двух важных интерфейсов приклад­ная программа сеть. Некоторые прикладные программы (особенно использующие интенсивный обмен данными например, коммуникационные шлю­зы) присоединяются к сети на уровне 5 (сеансовом), большинство же при­кладных программ присоединены к сети на уровне 6 (уровне представления). Наконец, ПО управления сетью образует уровень 7 (прикладной).

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

2. Место сетевого программного обеспечения среди системного и прикладного ПО

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

Начало истории сетей Microsoft было положено в MS-DOS версии 3.1; в ней к файловой системе FAT были добавлены необходимые расширения бло­кировки файлов и записей, которые обеспечили возможность работы с фай­лами MS-DOS сразу нескольким пользователям. Одновременно с выходом в 1984 году MS-DOS версии 3.1 Microsoft выпустила продукт под названием Microsoft Networks, получивший неформальное название MS-NET.

MS-NET установил de-facto ряд традиций, которые позже были перене­сены в Microsoft LAN Manager (несмотря на амбициозное наименование Microsoft LAN Manager сетевой ОС, на самом деле это набор сложных про­грамм и драйверов, добавляющих сетевые возможности к существующим ОС, в частности, к MS-DOS, OS/2 и UNIX, а потом и к WindowsNT).

Например, в случае выдачи пользователем или приложением запроса на ввод-вывод для удаленного файла, каталога или принтера система MS-NET определяла эту ситуацию и направляла запрос компоненту MS-NET, назы­вавшемуся редиректор (redirector). РедиректорMS-NET принимал запрос и посылал (перенаправлял  - redirect) его на удаленный сервер.

Другой особенностью MS-NET являлся встроенный протокол 8MB (Server Message Block), являющийся высокоуровневой спецификацией фор­мата посылаемых по сети сообщений. Для посылки имеющих формат 8MB запросов на другой компьютер используетсяAPI (Application Program Interface] под названием интерфейс NetBIOS (NetBIOS interface); впоследствии  протокол 8MB и API NetBIOSбыли использованы в многочисленных се­тевых продуктах, в том числе и в Windows NT.

Последнее, что было реализовано в MS-NET - это сетевой сервер (network server) находящееся на удаленном компьютере программное обес­печение, превращающее его в выделенный файл-сервер (или сервер печати). Это ПО просто контролировало сетевое соединение и ждало поступления по нему данных в формате 8MB, затем оно распаковывало их, определяло и вы­полняло запрашиваемую операцию (например, чтение файла), после чего по­сылало результат выполнения операции обратно в виде другого сообщения SMB.

Система MS-NET также включала набор утилит (со своим синтаксисом командной строки) для доступа к удаленным дискам и принтерам (например, многим известны команды формата NET USE X: \\SERVER\SHARE); до сих пор начинающиеся с символов \\ имена обозначают сетевые ресурсы и на­зываются именами единого соглашения об именовании (UNC, Uniform Naming Convention).

Серьезным шагом к интеграции сетевого ПО в ОС явилась система NetWare фирмы Novell, называемая (с большей или меньшей долей истинно­сти) сетевой ОС. В настоящее время среда NetWare способна поддерживать рабочие станции, управляемые MS-DOS, Windows,OS/2, UNIX, Mac System 7 и др., обладает развитой системой защиты данных (например, уровень при­вилегий доступа может быть указан отдельно для каждого каталога).

NetWare включает систему защиты при отказах оборудования (SFT, System Fault Tolerant) трех уровней

1.  Дублирование на том же диске критических данных (особенно катало­гов и таблиц распределения ресурсов).

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

3. Дублирование сетевого сервера (второй сервер находится в горячем ре­зерве и вступает в строй при аварии первого).

Большинство этих использованных в NetWare компонентов системы защиты применены (и получили дальнейшее развитие) вWindowsNT.

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

Windows98 и далеко не всем пришлось по вкусу). Широко разрекламиро­ванная ОС Whistler также должна обладать всеми этими свойствами. Заме­тим, что всеми перечисленными возможностями Unix-подобные ОС облада­ют практически с самого рождения.

Таким образом, компоненты сетевого ПО, появившиеся вначале как (не­обязательные) дополнения и расширения существующих ОС, в современных ОС являются встроенными (пока опциональными) компонентами системного ПО.

3. ФОРМАЛЬНЫЕ МЕТОДЫ ОПИСАНИЯ ПРОТОКОЛОВ

Число эксплуатируемых в настоящее время протоколов обмена данными велико; при этом разрабатываются все новые протоко­лы, обеспечивающие лавинное развитие сетевых технологий (появилась но­вая область вычислительной техники, называемая протокольной технологи­ей).

Классическое (неформально-словесное, например, ранее упомянутые RFC-документы) описание протокольных соглашений имеет ряд недостатков; важнейшие из них не позволяющая однозначно согласовывать разрабаты­ваемые стандарты субъективная природа восприятия словесных описаний (следствие описания не имеют полноты и основы для анализа), возникают трудности и труднолокализируемые ошибки при создании реализующих эти протоколы программных и аппаратных средств.

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

Формальные методы описания протоколов могут быть разбиты на две группы методы первой группы рассматривают объект как автомат (т.н. ав­томатные методы), методы второй группы как черный ящик, характери­зующийся только внешним поведением (т.н. методы последовательностей).

В качестве представителя первой группы может быть приведен язык ESTELLE (Extended State Transition Language), второй языкLOTOS (Language of Temporal Ordering Specification); оба языка разработаны Меж­дународной организацией стандартов (ISO) и служат базовыми средствами для описания разрабатывающих международных стандартов.

Язык ESTELLE (1983 г.) основан на объединении логики конечного ав­томата (при добавлении элементов описания архитектурных особенностей протокольных систем) и языка программирования Pascal; применяемые в языке LOTOS (1984 г.) методы основаны на концепции временного упорядо­чения примитивов взаимодействия.

В СССР для конкретного программно-аппаратного окружения был раз­работан (в рамках инструментального комплекса Архитектор) реализую­щий автоматный метод язык ОСА (Описание Сетевых Архитектур, основы и принципы языка впервые опубликованы в 1983 г), .предназначенный для реализации протокольных архитектур на вычислительных комплексах Эль­брус. В комплект системы входят развитые средства анализа описаний на языке ОСА и средства тестирования и отладки (под конкретную аппаратную часть). С помощью языка ОСА были разработаны специализированные про­токолы канального и сетевого уровней, транспортный и сеансовый протокол, протоколы для передачи информации и файлов, удаленного диалога и прото­кол удаленного запуска заданий (некоторый функциональный аналог RPC в WindowsNT).

Кроме вышеприведенных, известны системы проектирования и описа­ния протоколов FAPL (Format and Access Protocol Language,1978), PANDORA (Protocol Analysis, Design and OpeRation Assesment, 1982), PDIL (Protocol Description and Implementation Language, 1982), ПРАНАС (Каунас­ский политехнический институт, 1985) и др.

Как и в случае традиционных языков программирования, исходный текст на языке формального описания протоколов транслируется (после этапа отладки) в машинный код, исполняемый часто (специализированными) про­цессорами передачи сообщений (IMP - InterfaceMessage Processor).

4. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ АНАЛИЗА И ОПТИМИЗАЦИИ СЕТИ

В последние годы появился новый тип (сетевого) программного обеспе­чения, призванный обеспечивать эффективную работу сетей ЭВМ.

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

Пожалуй, впервые указанные проблемы проявились в 70-х годах в связи с постройкой и эксплуатацией сети принадлежащего Министерству обороны США Управления перспективных исследований (DARPA), принятое назва­ние сеть ARPANET; в настоящее время данная сеть считается прообразом глобальной сети InterNet.

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

ARPANET уже к 1975 году обеспечивала службу передачи сообщений между почти 100 ЭВМ, географически разнесенным по континентальной час­ти США и подключенных спутниковой связью (через Гавайи) к нескольким точкам в Европе, причем соединенные сетью ARPANET вычислительные машины во многих отношениях являлись несовместимыми друг с другом по аппаратному и программному обеспечению. Именно тогда был обеспечен сетевой доступ к мощнейшей для того времени ЭВМ ILLIAC IV и были ши­роко применены (с целью разгрузки вычислительных машин от выполнения задач обработки необходимых для функционирования сети сообщений) вы­шеупомянутые IMP.

Сеть ARPANET была спроектирована как для быстрой доставки корот­ких диалоговых сообщений, так и для обеспечения высокой скорости переда­чи длинных файлов, при этом стратегия выбора маршрута в сети принимает­ся в каждом процессоре IMP на основе получаемой от соседних процессоров IMP информации и местной информации, включающей сведения о состоянии каналов данного IМР-процессора.

Заметим, что сети общего пользования сложной топологии с коммутаци­ей пакетов появились не только в США (сети ARPANET иTELNET), но и в Канаде (DATAPAC), Англии (EPSS), Европе (EIN), Франции (TRANSPAC), Японии, Испании, Швеции и некоторых других странах.

В связи с проектированием и эксплуатацией сети ARPANET формули­ровались и решались задачи анализа и проектировании сетей нескольких ти­пов. Базовой задачей является анализ задержки определение средней за­держки передачи сообщения по заданному пути в сети (от конкретного ис­точника к конкретному получателю сообщений). Конечным результатом яв­ляется зависимость задержки от интенсивности требований на обслуживание; обычно график этой зависимости имеет начальный малоизменяемый участок при изменении нагрузки от нуля до некоторой пороговой величины и экспо­ненциально возрастает при нагрузке выше пороговой (соответствующей на-грузке насыщения. сети\ нагрузка насыщения сети соответствует блокировке сети по данному маршруту.

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

Наиболее сложной задачей является задача выбора оптимальных (в со­ответствие с определенным критерием оптимальности обычно стоимости) параметров сети (в основном маршрутов передачи сообщений между узлами сети при заданной топологии) при заданной максимальной средней задерж­ке (ВТПС/РП-задача); часто используют ВМУР (Вогнутый Метод Устране­ния Ребер} и МЗР (Метод Замены Ребер) алгоритмы решения задачи.

Хорошая процедура выбора мар­шрута должна

1.  Обеспечивать быструю и надежную доставку сообщений.

2. Адаптироваться к изменениям топологии сети, происходящим в резуль­тате повреждений узлов и каналов.

3. Адаптироваться  к меняющейся  нагрузке  между  парами   источник-получатель .

4. Направлять пакеты в сторону от временно перегруженных узлов в сети.

5. Определять связность сети.

6. Допускать простое и автоматическое снятие и установку процессоров IMP.

Такую задачу можно решить лишь путем применения распределенного алгоритма управления. Это значит, что не существует центра, который при­нимал бы обязательные для всей сети решения, все узлы выносят местные решения относительно маршрутов динамическим образом. Основанное на подобных предпосылках программное обеспечение было протестировано применительно к сети ARPANET; было показано, что процедура выбора маршрутов является в основном стабильной и приводит к очень хорошим ре­зультатам, в разумной степени реагирует на повреждения узлов и каналов сети, автоматически узнает о появлении нового узла (как только он присое­диняется к сети или возвращается после исправления), эта особенность сети ARPANET является замечательной технической стороной данной сети. Для заинтересовавшихся проблемой рекомендуется работа; там же приведена обширная библиография. Заметим, что в дальнейшем многие из перечислен­ных разработок были использованы в сети InterNet.

Таким образом, логично предположить, что в состав сетевого ПО (даже для ЭВМ уровня персонального компьютера) все чаще будут включаться ре­шающее вышеприведенные задачи программные компоненты. Например, для обслуживания баз данных фирмой Inprise Corp. в настоящее время разраба­тывается эффективная технология выбора сервера с учетом загрузки процес­соров и сетевого трафика функционирующих в сети серверов, что позво­лит более равномерно распределять нагрузку между серверами); в будущем они станут обязательными для системы распределенных вычислений (рас­пределенной ОС). Представляет интерес также разработанная для сетиInterNet технология (и соответствующий протокол) MPLS (Multiprotocol Label Switching - многопроцессорная коммутация с заменой меток),реализующаяконцепции известной ATM-технологии в обобщенном виде (Asynchronous Transfer Mode - поддерживаемая консорциумом известных компаний техно­логия, основанная на использовании упаковки разнородных типов данных в ячейки cells и создании функционирующих определенное время вирту­альных соединений в физическом канале связи с целью обеспечения гаранти­рованной по времени доставки сообщений; в настоящее время ATN-технология считается перспективной для транспортировки чувствительных к временной задержке сообщений например, цифровой телефонии, телевиде­ния).

5. ИНТЕРФЕЙС СЕТЕВОЙ БАЗОВОЙ СИСТЕМЫ ВВОДА/ВЫВОДА

Интерфейс сетевой базовой системы ввода/вывода (NetBIOS) пред­ставляет собой разработанный фирмой Microsoft Corp. интерфейс програм­мирования, позволяющий обмениваться запросами ввода-вывода с удален­ным компьютером. Пользуясь функциями NetBIOSа, программист создает приложения, независимые от конкретной сетевой аппаратуры.

Расширенный пользовательский интерфейс транспортного протокола локальной сети (NetBEUI, NetBios Extended User Interfacetransport) создан фирмой IBM для работы под сетевым интерфейсом NetBIOS фирмы Microsoft Corp; протокол NetBEUI широко применялся в первых версиях WindowsNT. Несмотря на то, что этот протокол обеспечивает наивысшую скорость рабо­ты, ряд присущих ему недостатков (таких, как невозможность маршрутиза­ции и сильная зашумленность в большой сети) позволяет эффективно ис­пользовать его только в небольших локальных сетях.

NetBIOS является интерфейсом сеансового уровня, могущим быть ис­пользованным приложениями для связи с NetBIOS-совместимыми транс­портными протоколами (например, протокол NetBEUI). Двусторонние со­единения между ЭВМ с NetBIOS реализует между ними логическое соедине­ние (сеанс). После установления логического соединения компьютеры могут обмениваться данными в формате блоков управления сетью (NCB, Network Control Block} или в формате блоков сообщений сервера (8MB, Server Message Block}, при настройке сетевой компоненты NetBIOS указывается сетевое имя компьютера (имя, под которым этот компьютер будет виден другим поль­зователям сети).

Функции NetBIOS обычно не используются программистом напрямую вследствие низкого их уровня, хотя в принципе это возможно (существуют справочники по их применению, например фирменное руководство NetBIOS programmer reference фирмы IBM Corp.).

6. УДАЛЕННЫЙ ВЫЗОВ ПРОЦЕДУР

Средство удаленного вызова процедур (RPC, Remote Procedure Call) по­зволяет создавать приложения, состоящие из произвольного числа процедур, часть которых выполняется локально (на данном компьютере), а часть по сети на удаленных компьютерах. Таким образом, RPC представляет модель работы с сетью, ориентированную на процедуры, а не на транспорт (передачу данных), что позволяет упростить разработку распределенных приложений.

Традиционно сетевое ПО основывается на модели ввод-вывод. В ОС WindowsNT сетевая операция начинается с того, что приложение иницииру­ет запрос операции удаленного ввода-вывода. ОС обрабатывает запрос, пере­давая его редиректору (выступающему в качестве удаленной файловой сис­темы). После обработки запроса и возврата данных удаленной файловой сис­темой сетевая плата генерирует прерывание. Ядро ОС обрабатывает это пре­рывание, а исходная программа ввода-вывода возвращает результаты вызы­вающей программе.

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

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

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

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

Функционирует приложение RPC следующим образом. В процессе рабо­ты оно вызывает как локальные, так и отсутствующие (недоступные) на ло­кальной машине процедуры. Для обработки последнего случая приложение связывается с локальной DLL, содержащей по одной процедуре-заглушке (stub procedure} для каждой из удаленной процедур. Процедура-заглушка имеет то же имя и интерфейс, что и удаленная процедура, однако вместо выполнения соответствующей операции заглушка принимает передаваемые ей параметры и выполняет операцию их преобразования (marsaling) для передачи по сети.

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

Далее заглушка вызывает процедуры библиотеки RPC периода выполне­ния (Run Time); они находят компьютер, на котором расположены удаленные процедуры, определяют используемые этим компьютером механизмы транс­порта и посылают запрос (при помощи локального программного обеспече­ния сетевого транспорта). Когда удаленный компьютер (выполняющий в этот момент функцию сервера) получает запрос RPC, он выполняет обратное пре­образование параметров, реконструирует оригинальный вызов процедуры и осуществляет фактический вызов ее. По окончании работы сервер выполняет обратную последовательность действий для возврата результатов вызываю­щей программе. На рис.5.3 схематично показано сетевое взаимодействие клиентского компьютера с серверными ЭВМ с использование RPC-библиотеки периода выполнения.

Кроме библиотеки периода выполнения, в состав средств RPC фирмы Microsoft Corp. Входит компилятор MIDL (Microsoft InterfaceDefinition Language - язык описания интерфейса фирмы Microsoft). Использованиекомпилятора MIDL упрощает написание приложенийRPC. Программист пишет набор обычных функций (например, на языке С или C++), описываю­щих удаленные процедуры, затем он добавляет к этим прототипам некото­рую дополнительную информацию (например, уникальный для данной сети идентификатор пакета процедур и номер версии плюс атрибуты, указываю­щие, является ли параметр процедуры входом, выходом или и тем и другим). Фактически из этих модифицированных прототипов и состоит файл на языке описания интерфейса (IDL, Interface Definition Language).

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

Библиотека RFC периода выполнения использует для взаимодействия с транспортным протоколом единый интерфейс доступа к транспорту RPC (RPC transport interface). Этот интерфейс служит прослойкой между средст­вом RPC и транспортным протоколом, которая отображает операции RPC в функции, предоставляемые транспортным протоколом.

Средство RPC для WindowsNT предоставляет DLL-компоненты доступа к транспортному протоколу для именованных каналов,NetBIOS, ТСРАР и DECnet, имеется возможность разработки дополнительных DLL с целью под­держки других транспортных протоколов. Сходным образом средство RPC поддерживает работу с различными средствами защиты (при отсутствии не­штатных DLL защиты программное обеспечение RPC для WindowsNT ис­пользует встроенную защиту именованных каналов).

Для обеспечения взаимодействия средства RPC с приложениями RPC на другой ЭВМ они должны использовать одинаковые соглашения RPC. Microsoft RPC соответствует стандарту RPC, установленному Open Software Foundation (OSF) в спецификации среды распределенных вычислений (ОСЕ, Distribute Calculation Environment). Таким образом, написанные с использо­ванием Microsoft RPCприложения могут вызывать удаленные процедуры на других системах, использующих стандарт DCE.

Большинство сетевых сервисов WindowsNT являются приложениями RPC и поэтому могут вызываться как локальными процессами, так и процес­сами на удаленных машинах. Это значит, что удаленный компьютер может обращаться к сервисам данной ЭВМ для просмотра совместно используемых ресурсов, открытых файлов, очередей печати или активных пользователей на этом сервере, либо он может вызвать сервис сообщений для посылки сооб­щений (при наличии соответствующих прав доступа).

Существуют более совершенные механизмы реализации вызова удален­ных процедур - асинхронные вызовы удаленных функций(ARPC, Asynchronous Remote Procedure Cal), позволяющие на основе применения функций отклика (call-back function) избежать приостановки выполнения прикладной программы на локальной машине. Для связи с удаленными сис­темами RPC может использовать сервис NetBIOS, Windows Sockets и другие доступные средства (например, именованные каналы для WindowsNT). Для вызова процедур, расположенных на том же компьютере, что и вызывающая программа, и обмена информацией с ними служит механизмы вызова локаль­ных процедур (LPC, Local Procedure Call) или упрощенного вызова удаленных процедур (LRPC, Lightweight Remote Procedure Call). Однако вышеуказанные средства доступны лишь в WindowsNT.

Ваш отзыв


3 восемь =