Межпроцессное взаимодействие в ос windows реферат

Обновлено: 06.02.2023

Межпроцессное взаимодействие (англ. inter-process communication, IPC ) — обмен данными между потоками одного или разных процессов. Реализуется посредством механизмов, предоставляемых ядром ОС или процессом, использующим механизмы ОС и реализующим новые возможности IPC. Может осуществляться как на одном компьютере, так и между несколькими компьютерами сети [1] .

Содержание

Общие положения

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

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

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

Ресурс, который допускает обслуживание только одного пользователя за один раз, называетсякритическим ресурсом. Если несколько процессов хотят пользоваться критическим ресурсом в режиме разделения времени, им следует синхронизировать свои действия таким образом, чтобы этот ресурс всегда находился в распоряжении не более чем одного их них.

Участки процесса, в которых происходит обращение к кри¬тическим ресурсам, называются критическими участками. Для организации коммуникации между одновременно работающими процессами применяются средства межпроцессного взаимодействия (Interprocess Communication — IPC).

Выделяются три уровня средств IPC:

• локальный;

• удаленный;

• высокоуровневый.

Удаленные IPC предоставляют механизмы, которые обеспечивают взаимодействие как в пределах одного процессора, так и между программами на различных процессорах, соединенных через сеть. Сюда относятся удаленные вызовы процедур (Remote Procedure Calls — RPC), сокеты Unix, а также TLI (Transport Layer Interface — интерфейс транспортного уровня) фирмы Sun [2] .

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

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

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

• Голодание процессов. Организация дисциплины доступа может привести к ситуации, когда процесс будет длительно ждать своей очереди для записи данных. Поэтому иногда нужно организовывать очереди с приоритетами.

• Управление потоком. Если нельзя точно определить, какой из процессов запрашивает или возвращает свои данные в нужный компьютер первым, используется так называемое взаимодействие по модели «клиент-сервер». При этом используются один или несколько клиентов и один сервер. Клиент посылает запрос серверу, а сервер отвечает на него. После этого клиент должен дождаться ответа сервера, чтобы продолжать дальнейшее взаимодействие. Такое поведение называется управлением потоком. При одновременном доступе здесь также могут использоваться очереди с приоритетами [3] .

• Тупик (deadlock). Классический тупик возникает, если процесс A получает доступ к файлу A и ждет освобождения файла B. Одновременно процесс B, получив доступ к файлу B, ждет освобождения файла A. Оба процесса теперь ждут освобождения ресурсов другого процесса и не освобождают при этом собственный файл.

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

Каналы

Канал (pipe) представляет собой средство связи стандартного вывода одного процесса со стандартным вводом другого. Каналы старейший из инструментов IPC, существующий приблизительно со времени появления самых ранних версий оперативной системы UNIX.

Для реализации IPC возможно использование полудуплексных и/или именованных каналов (FIFO).

Полудуплексные каналы

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

Из этого рисунка легко увидеть, как файловые дескрипторы связаны друг с другом. Если процесс посылает данные через канал (fd0), он имеет возможность получить эту информацию из fd1. Однако этот простенький рисунок отображает и более глобальную задачу. Хотя канал первоначально связывает процесс с самим собой, данные, идущие через канал, проходят через ядро. В частности, в Linux каналы внутренне представлены корректным inode. Конечно, этот inode существует в пределах самого ядра, а не в какой-либо физической файловой системе. Эта особенность откроет нам некоторые привелекательные возможности для ввода/вывода, как мы увидим немного позже. Зачем же нам неприятности с созданием канала, если мы всего-навсего собираемся поговорить сами с собой? На самом деле, процесс, создающий канал, обычно порождает дочерний процесс. Как только дочерний процесс унаследует какой-нибудь открытый файловый дескриптор от родителя, мы получаем базу для мультипроцессовой коммуникации (между родителем и потомком). Рассмотрим эту измененную версию нашего рисунка:

Теперь мы видим, что оба процесса имеют доступ к файловым дескрипторам, которые основывают канал. На этой стадии должно быть принято критическое решение. В каком направлении мы хотим запустить данные? Потомок посылает информацию к родителю или наоборот? Два процесса взаимно согласовываются и «закрывают» неиспользуемый конец канала. Пусть потомок выполняет несколько действий и посылает информацию родителю обратно через канал. Наш новый рисунок выглядел бы примерно так:

Конструкция канала теперь полная. Чтобы использовать его, можно применять системные вызовы, подобные тем, которые нужны для ввода/вывода в файл или из файла на низком уровне (вспомним, что в действительности каналы внутренне представлены как корректный inode). Это означает, что для чтения из канала можно использовать вызов read(), а для записи — write(). Примечания:

• Двусторонние каналы могут быть созданы посредством открывания двух каналов и правильным переопределением файловых дескрипторов в процессе-потомке.
• Вызов pipe() должен быть произведен ПЕРЕД вызовом fork(), или дескрипторы не будут унаследованы процессом-потомком! (то же для popen()).
• С полудуплексными каналами любые связанные процессы должны разделять происхождение. Поскольку канал находится в пределах ядра, любой процесс, не состоящий в родстве с создателем канала, не имеет способа адресовать его. Это не относится к случаю с именованными каналами (FIFOS).

Именованные каналы (FIFO: First In First Out)

Именованные каналы во многом работают так же, как и обычные каналы, но все же имеют несколько заметных отличий:

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

Операции ввода/вывода с FIFO, по существу, такие же, как для обычных каналов, за одним исключением. Чтобы физически открыть проход к каналу, должен быть использован системный вызов «open» или библиотечная функция. С полудуплексными каналами это невозможно, поскольку канал находится в ядре, а не в физической файловой системе.

Если FIFO открыт для чтения, процесс его блокирует до тех пор, пока какой-нибудь другой процесс не откроет FIFO для записи.

Сигналы

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

Механизм передачи сигналов состоит из следующих частей:

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

Отдельные сигналы подразделяются на три класса:

• системные сигналы (ошибка аппаратуры, системная ошибка и т.д.);
• сигналы от устройств;
• сигналы, определенные пользователем.

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

Известно три варианта реакции на сигналы:

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

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

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

Семафоры

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

Над каждым семафором, принадлежащим некоторому множеству, можно выполнить любую из трех операций:

• увеличить значение;
• уменьшить значение;
• дождаться обнуления.

Для выполнения первых двух операций у процесса должно быть право на изменение, для выполнения третьей достаточно права на чтение. Чтобы увеличить значение семафора, системному вызову semop следует передать требуемое число. Чтобы уменьшить значение семафора, нужно передать требуемое число, взятое с обратным знаком; если результат получается отрицательным, операция не может быть успешно выполнена. Для третьей операции нужно передать 0; если текущее значение семафора отлично от нуля, операция не может быть успешно выполнена.

Разделяемая память

Сокеты

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

Основные типы сокетов

Поточный — обеспечивает двухсторонний, последовательный, надежный, и недублированный поток данных без определенных границ. Тип сокета — SOCK_STREAM, в домене Интернета он использует протокол TCP.

Сокет последовательных пакетов — обеспечивает двухсторонний, последовательный, надежный обмен датаграммами фиксированной максимальной длины. Тип сокета — SOCK_SEQPACKET. Для этого типа сокета не существует специального протокола.

IPC: основы межпроцессного взаимодействия

Любая операционная система была бы весьма ущербна, если бы замыкала выполняющееся приложение в собственном темном мирке без окон и дверей, без какой-либо возможности сообщить другим программам какую-либо информацию. Если посмотреть внимательно, можно заметить, что далеко не все приложения являются самодостаточными. Очень многим, если не большей части, требуется информация от других приложений, либо они должны эту информацию сообщать. Именно поэтому в операционную систему встраивается множество механизмов, которые обеспечивают т.н. Interproccess Communication (IPC) — то есть межпроцессное взаимодействие.

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

Рассмотрим подробнее несколько ключевых примеров, демонстрирующих важность IPC. Вам, возможно это покажется неправдоподобным, но зачатки IPC существовали еще в MS-DOS — и это несмотря на то, что MS-DOS при всем желании трудно назвать многозадачной средой. В самом деле, когда вы в командной строке вводили подобную инструкцию :

происходило следующее: выполнялась команда DIR и ее вывод записывался во временный текстовый файл. После этого содержимое файла подавалось на вход команды MORE. В результате вы получали листинг каталогов, который в случае большого количества каталогов не уезжал мгновенно за экран, а мог скроллироваться с помощью клавиши Enter. Конечно же это очень примитивный IPC, но его наличие показывает, что уже тогда такой механизм был востребован и в какой-то мере реализован.

Примеры использования IPC охватывают гораздо большее количество программ и приложений, чем вы скорее всего думаете. Когда вы выходите в интернет, ваш браузер — одна программа (процесс) — взаимодействует с web-сервером — другой программой (процессом). Эти программы выполняются на разных компьютерах; браузер на вашем, сервер — где-то еще. И вас не волнует, какая ОС установлена на сервере и какая там платформа.
Или, например, вы работаете с удаленной базой данных. Ваше клиентское приложение — это один процесс, на сервере базы данных запущен другой процесс. Процесс на сервере выполняет запросы к БД, поступающие от вашего процесса.

ПРИМЕЧАНИЕ
Вообще, для сетевых форм IPC (но не обязательно только для них) очень часто используется концепция «клиент-сервер». Как вы понимаете, «клиент» — это приложение, которому требуются данные, «сервер» — приложение, предоставляющее данные.

А если брать только взаимодействие программ, выполняющихся на одном компьютере, самым банальным примером будет следующий: текст из вашего текcтового редактора передается в электронную таблицу или программу для верстки. Да-да, наш старый знакомый буфер обмена — это тоже один из механизмов IPC!
И еще можно было бы привести очень много примеров.

Средств, обеспечивающих взаимодействие между процессами, создано достаточно много. Огромное их количество реализовано в Windows 9x, еще больше — в Windows NT/2000. Теперь нужно приличное количество времени, чтобы хотя бы познакомиться со всеми! Замечу, что нет, и наверное в принципе не может быть универсального способа обмена данными, который годился бы на все случаи жизни — все равно в некоторых случаях использование другого способа будет предпочтительнее. Но я надеюсь, что после прочтения этой статьи вы сможете достаточно уверенно ориентироваться в мире IPC и обоснованно выбирать тот или иной метод.

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

Вообще, правильнее было бы называть эти механизмы «Interthread Communication» — межпотоковое взаимодействие. Если вы помните, выполняются именно потоки, они же и обмениваются данными. Однако, смысл для отдельных механизмов взаимодействия появляется только в том случае, если эти потоки принадлежат разным процессам. Ведь потоки, выполняющиеся в рамках одного процесса, вовсе не нуждаются в дополнительных средствах для общения между собой. Так как они разделяют одно адресное пространство, обмен данными могут обеспечить обычные переменные. Таким образом, IPC становится необходим в том случае, если поток одного процесса должен передать данные потоку другого процесса.

Теперь давайте рассмотрим основные виды IPC и случаи, в которых они используются.

Буфер обмена (clipboard)

Это одна из самых примитивных и хорошо известных форм IPC. Он появился еще в самых ранних версиях Windows. Основная его задача — обеспечивать обмен данными между программами по желанию и под контролем пользователя. Впрочем, вы наверняка сами неплохо знаете, как используется буфер обмена. Не рекомендуется использовать его для внутренних нужд приложения, и не стоит помещать туда то, что не предназначено для прямого просмотра пользователем.

Разделяемая память (shared memory)

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

Библиотеки динамической компоновки (DLL)

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

Протокол динамического обмена данными (Dynamic Data Exchange, DDE)

Этот протокол выполняет все основные функции для обмена данными между приложениями. Он очень широко использовался до тех пор, пока для этих целей не стали применять OLE (впоследствии ActiveX). На данный момент DDE используется достаточно редко, в основном для обратной совместимости.

Больше всего этот протокол подходит для задач, не требующих продолжительного взаимодействия с пользователем. Пользователю в некоторых случаях нужно только установить соединение между программами, а обмен данными происходит без его участия. Замечу, что все это в равной степени относится и к технологии OLE/ActiveX.

OLE/ActiveX

Это действительно универсальная технология, и одно из многих ее применений — межпроцессный обмен данными. Хотя cтоит думаю отметить, что OLE как раз для этой цели и создавалась (на смену DDE), и только потом была расширена настолько, что пришлось поменять название ;-). Специально для обмена данными существует интерфейс IDataObject. А для обмена данными по сети используется DCOM, которую под некоторым углом можно рассматривать как объединение ActiveX и RPC.

Каналы (pipes)

Каналы — это очень мощная технология обмена данными. Наверное, именно поэтому в полной мере они поддерживаются только в Windows NT/2000. В общем случае канал можно представить в виде трубы, соединяющей два процесса. Что попадает в трубу на одном конце, мгновенно появляется на другом. Чаще всего каналы используются для передачи непрерывного потока данных.

Каналы делятся на анонимные (anonymous pipes) и именованные (named pipes). Анонимные каналы используются достаточно редко, они просто передают поток вывода одного процесса на поток ввода другого. Именованные каналы передают произвольные данные и могут работать через сеть. (Именованные каналы поддерживаются только в WinNT/2000.)

Сокеты (sockets)

Это очень важная технология, т.к. именно она отвечает за обмен данными в Интернет. Сокеты также часто используются в крупных ЛВС. Взаимодействие происходит через т.н. разъемы-«сокеты», которые представляют собой абстракцию конечных точек коммуникационной линии, соединяющей два приложения. С этими объектами программа и должна работать, например, ждать соединения, посылать данные и т.д. В Windows входит достаточно мощный API для работы с сокетами.

Почтовые слоты (mailslots)

Объекты синхронизации

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

Microsoft Message Queue (MSMQ)

Удаленный вызов процедур (Remote Procedure Call, RPC)

Строго говоря, это не совсем технология IPC, а скорее способ значительно расширить возможности других механизмов IPC. С помощью этой технологии общение через сеть становится совешенно прозрачным как для сервера, так и для клиента. Им обоим начинает казаться, что их «собеседник» расположен локально по отношению к ним .

Резюме

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

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

в этом разделе объясняются различные способы выполнения межпроцессного взаимодействия (IPC) между приложениями универсальная платформа Windows (UWP) и приложениями Win32.

Услуги для приложений

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

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

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

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

Упакованные приложения с возможностью рунфуллтруст могут регистрировать необработанные COM-серверы для IPC с помощью манифеста пакета. Это называется упакованным com.

Файловая система

BroadFileSystemAccess

Упакованные приложения могут выполнять IPC с помощью обширной файловой системы, объявляя ограниченную возможность broadFileSystemAccess . эта возможность предоставляет Windows. служба хранилища Интерфейсы API и ксксксфромапп Win32 API обращаются к широкой файловой системе.

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

PublisherCacheFolder

PublisherCacheFolder позволяет упакованным приложениям объявлять папки в своем манифесте, которые могут использоваться совместно с другими пакетами одним и тем же издателем.

Папка общего хранилища имеет следующие требования и ограничения.

• Данные в папке общего хранилища не архивируются и не перемещаются.
• Пользователь может очистить содержимое папки общего хранилища.
• Нельзя использовать папку общего хранилища для обмена данными между приложениями разных издателей.
• Нельзя использовать папку общего хранилища для обмена данными между разными пользователями.
• В папке общего хранилища нет управления версиями.

Если вы публикуете несколько приложений и ищете простой механизм обмена данными между ними, PublisherCacheFolder — подходящий простой вариант на основе файловой системы.

шаредакцесссторажеманажер

Шаредакцесссторажеманажер используется совместно со службами приложений, активацией протоколов (например, лаунчурифорресултсасинк) и т. д., чтобы совместно использовать сторажефилес через маркеры.

фуллтрустпроцесслаунчер

Благодаря возможности рунфуллтруст Упакованные приложения могут запускать процессы с полным доверием в одном пакете.

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

LaunchUriForResultsAsync

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

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

Замыкание на себя

Замыкание на себя — это процесс связи с сетевым сервером, который прослушивает localhost (адрес замыкания на себя).

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

• Все Упакованные приложения, участвующие в подключениях замыкания на себя, должны объявлять privateNetworkClientServer возможности в privateNetworkClientServer .
• Два упакованных приложения могут обмениваться данными через замыкание на себя, объявляя лупбаккакцессрулес в манифестах пакетов.
  • Каждое приложение должно перечислить в лупбаккакцессрулес. Клиент объявляет правило «out» для сервера, а сервер объявляет правила «in» для поддерживаемых клиентов.

  имя семейства пакетов, необходимое для распознавания приложения в этих правилах, можно найти с помощью редактора манифеста пакета во Visual Studio во время разработки, через центр партнеров для приложений, опубликованных с помощью Microsoft Store, или с помощью команды PowerShell Get-AppxPackage для уже установленных приложений.

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

  • Все Упакованные приложения, участвующие в подключениях замыкания на себя, privateNetworkClientServer должны объявлять возможности в privateNetworkClientServer .
  • Если упакованное приложение подключается к неупакованному приложению или службе, выполните команду CheckNetIsolation.exe LoopbackExempt -a -n=
  должны выполняться постоянно, пока упакованное приложение прослушивает подключения.
  • -is флаг был введен в Windows 10 версии 1607 (10,0; Сборка 14393).

  имя семейства пакетов, необходимое для -n флага -n , можно найти в редакторе манифеста пакета в Visual Studio во время разработки, через центр партнеров для приложений, опубликованных с помощью Microsoft Store, или с помощью команды PowerShell Get-AppxPackage для уже установленных приложений.

  Каналы

  Каналы обеспечивают простое взаимодействие между сервером канала и одним или несколькими клиентами канала.

  Анонимные каналы и именованные каналы поддерживают следующие ограничения:

  • По умолчанию именованные каналы в упакованных приложениях поддерживаются только между процессами в одном пакете, если только процесс не имеет полного доверия.
  • Именованные каналы можно совместно использовать в пакетах, следуя рекомендациям по предоставлению общего доступа к именованным объектам.
  • Именованные каналы в упакованных приложениях должны использовать синтаксис \.pipeLOCAL для имени канала.

  Реестр

  Использование реестра для IPC, как правило, не рекомендуется, но поддерживается для существующего кода. Упакованные приложения имеют доступ только к тем разделам реестра, для доступа к которым у них есть разрешение.

  Классические приложения, Упакованные в MSIX, используют виртуализацию реестра , так что глобальные записи реестра содержатся в частном кусте в пакете MSIX. Это обеспечивает совместимость исходного кода при минимизации влияния на глобальные реестры и может использоваться для IPC между процессами в одном пакете. Если необходимо использовать реестр, то эта модель является предпочтительной, а управление глобальным реестром — с помощью.

  RPC можно использовать для подключения упакованного приложения к КОНЕЧНОЙ точке RPC Win32 при условии, что Пакетное приложение имеет правильные возможности для сопоставления ACL в КОНЕЧНОЙ точке RPC.

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

  Конечные точки RPC также могут быть доступен для конкретных упакованных приложений, чтобы ограничить доступ к конечной точке только этими приложениями без необходимости управления дополнительными возможностями. Вы можете использовать API деривеаппконтаинерсидфромаппконтаинернаме для получения идентификатора безопасности из имени семейства пакетов, а затем в списке ACL КОНЕЧНОЙ точки RPC с ИД безопасности, как показано в примере кустомкапабилити .

  Общая память

  Сопоставление файлов можно использовать для совместного использования файла или памяти между двумя или более процессами со следующими ограничениями:

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

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

  TCP и UDP сокеты. Адресные пространства портов. Понятие encapsulation. Encapsulation для UDP-протокола на сети Ethernet. Использование модели клиент-сервер для взаимодействия удаленных процессов. Организация связи между процессами с помощью датаграмм.

  Рубрика	Программирование, компьютеры и кибернетика
  Вид	контрольная работа
  Язык	русский
  Дата добавления	07.05.2012
  Размер файла	40,6 K

  Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

  Межпроцессное взаимодействие

  порт сервер датаграмма encapsulation

  Мы не будем вдаваться в детали реализации протоколов транспортного уровня, а лишь кратко рассмотрим их основные характеристики. К протоколам транспортного уровня относятся протоколы TCP и UDP.

  Полный адрес удаленного процесса или промежуточного объекта для конкретного способа связи с точки зрения операционных систем определяется парой адресов: .

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

  Поскольку уровень Internetсемейства протоколов TCP/IP умеет доставлять информацию только от компьютера к компьютеру, данные, полученные с его помощью, должны содержать тип использованного протокола транспортного уровня и локальные адреса отправителя и получателя. И протокол TCP, и протокол UDP используют непрямую адресацию.

  Итак, мы описали иерархическую систему адресации, используемую в семействе протоколов TCP/IP, которая включает в себя несколько уровней:

  · Физический пакет данных, передаваемый по сети, содержит физические адреса узлов сети (MAC-адреса) с указанием на то, какой протокол уровня Internet должен использоваться для обработки передаваемых данных (поскольку пользователя интересуют только данные, доставляемые затем на уровень приложений / процессов, то для него это всегда IP).

  · IP-пакет данных содержит 32-битовые IP-адреса компьютера-отправителя и компьютера-получателя, и указание на то, какой вышележащий протокол (TCP, UDP или еще что-нибудь) должен использоваться для их дальнейшей обработки.

  · Служебная информация транспортных протоколов (UDP-заголовок к данным и TCP-заголовок к данным) должна содержать 16-битовые номера портов для сокета отправителя и сокета получателя.

  Добавление необходимой информации к данным при переходе от верхних уровней семейства протоколов к нижним принято называть английским словом encapsulation (дословно: герметизация). На рисунке 1. приведена схема encapsulation при использовании протокола UDP на сети Ethernet.

  Рис. 1. Encapsulation для UDP-протокола на сети Ethernet

  Поскольку между MAC-адресами и IP-адресами существует взаимно однозначное соответствие, известное семейству протоколов TCP/IP, то фактически для полного задания адреса доставки и адреса отправления, необходимых для установления двусторонней связи, нужно указать пять параметров: транспортный протокол, IP-адрес отправителя, порт отправителя, IP-адрес получателя, порт получателя.

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

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

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

  · Сервер ждет запроса от клиентов, инициатором же взаимодействия выступает клиент.

  · Как правило, клиент обращается к одному серверу за раз, в то время как к серверу могут одновременно поступить запросы от нескольких клиентов.

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

  · И клиент, и сервер должны использовать один и тот же протокол транспортного уровня.

  Неравноправность процессов в модели клиент-сервер, как мы увидим далее, накладывает свой отпечаток на программный интерфейс, используемый между уровнем приложений / процессов и транспортным уровнем.

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

  Рассмотрим основные действия, которые нам необходимы в терминах абстракции socket для того, чтобы организовать взаимодействие между клиентом и сервером, используя транспортные протоколы стека TCP/IP.

  Организация связи между удаленными процессами с помощью датаграмм

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

  Все эти модельные действия имеют аналоги при общении удаленных процессов по протоколу UDP.

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

  Создание сокета производится с помощью системного вызова socket(). Для привязки созданного сокета к IP-адресу и номеру порта (настройка адреса) служит системный вызов bind(). Ожиданию получения информации, ее чтению и, при необходимости, определению адреса отправителя соответствует системный вызов recvfrom(). За отправку датаграммы отвечает системный вызов sendto().

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

  Сетевой порядок байт. Функции htons(), htonl(), ntohs(), ntohl()

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

  Как известно, порядок байт в целых числах, представление которых занимает более одного байта, может быть для различных компьютеров неодинаковым. Есть вычислительные системы, в которых старший байт числа имеет меньший адрес, чем младший байт (big-endianbyteorder), а есть вычислительные системы, в которых старший байт числа имеет больший адрес, чем младший байт (little-endianbyteorder). При передаче целой числовой информации от машины, имеющей один порядок байт, к машине с другим порядком байт мы можем неправильно истолковать принятую информацию. Для того чтобы этого не произошло, было введено понятие сетевого порядка байт, т.е. порядка байт, в котором должна представляться целая числовая информация в процессе передачи ее по сети (на самом деле — это big-endianbyteorder). Целые числовые данные из представления, принятого на компьютере-отправителе, переводятся пользовательским процессом в сетевой порядок байт, в таком виде путешествуют по сети и переводятся в нужный порядок байт на машине-получателе процессом, которому они предназначены. Для перевода целых чисел из машинного представления в сетевое и обратно используется четыре функции: htons(), htonl(), ntohs(), ntohl().

  Функции преобразования порядка байт

  Прототипы функций

  unsigned long inthtonl (

  unsigned long inthostlong);

  unsigned short inthtons (

  unsigned short inthostshort);

  unsigned long intntohl (

  unsigned long intnetlong);

  unsigned short intntohs (

  unsigned short intnetshort);

  Описание функций

  Функция htonl осуществляет перевод целого длинного числа из порядка байт, принятого на компьютере, в сетевой порядок байт.

  Функция htons осуществляет перевод целого короткого числа из порядка байт, принятого на компьютере, в сетевой порядок байт.

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

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

  В архитектуре компьютеров i80x86 принят порядок байт, при котором младшие байты целого числа имеют младшие адреса. При сетевом порядке байт, принятом в Internet, младшие адреса имеют старшие байты числа.

  Параметр у них — значение, которое мы собираемся конвертировать. Возвращаемое значение-то, что получается в результате конвертации. Направление конвертации определяется порядком букв h (host) и n (network) в названии функции, размер числа — последней буквой названия, то есть htons — это hosttonetworkshort, ntohl — networktohostlong.

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

  Функции преобразования IP-адресов inet_ntoa(), inet_aton()

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

  Функция возвращает 1, если в символьном виде записан правильный IP-адрес, и 0 в противном случае — для большинства системных вызовов и функций это нетипичная ситуация. Обратите внимание на использование указателя на структуру structin_addr в качестве одного из параметров данной функции. Эта структура используется для хранения IP-адресов в сетевом порядке байт. То, что используется структура, состоящая из одной переменной, а не сама 32-битовая переменная, сложилось исторически, и авторы в этом не виноваты.

  Для обратного преобразования применяется функция inet_ntoa().

  Функции преобразования IP-адресов

  Прототипы функций

  intinet_aton (const char *strptr,

  char *inet_ntoa (structin_addr *addrptr);

  Описание функций

  Функция inet_aton переводит символьный IP-адрес, расположенный по указателю strptr, в числовое представление в сетевом порядке байт и заносит его в структуру, расположенную по адресу addrptr. Функция возвращает значение 1, если в строке записан правильный IP-адрес, и значение 0 в противном случае. Структура типа structin_addr используется для хранения IP-адресов в сетевом порядке байт и выглядит так:

  То, что используется адрес такой структуры, а не просто адрес переменной типа in_addr_t, сложилось исторически.

  Функция inet_ntoa применяется для обратного преобразования. Числовое представление адреса в сетевом порядке байт должно быть занесено в структуру типа structin_addr, адрес которой addrptr передается функции как аргумент. Функция возвращает указатель на строку, содержащую символьное представление адреса. Эта строка располагается в статическом буфере, при последующих вызовах ее новое содержимое заменяет старое содержимое.

  Функция bzero()

  Функция 2 настолько проста, что про нее нечего рассказывать. Все видно из описания.

  Функция bzero

  Прототип функции

  void bzero (void *addr, int n);

  Описание функции

  Функция bzero заполняет первые n байт, начиная с адреса addr, нулевыми значениями. Функция ничего не возвращает.

  Теперь мы можем перейти к системным вызовам, образующим интерфейс между пользовательским уровнем стека протоколов TCP/IP и транспортным протоколом UDP.

  Создание сокета. Системный вызов socket()

  Для создания сокета в операционной системе служит системный вызов socket(). Для транспортных протоколов семейства TCP/IP существует два вида сокетов: UDP-сокет — сокет для работы с датаграммами, и TCP сокет — потоковыйсокет. Однако понятие сокета не ограничивается рамками только этого семейства протоколов. Рассматриваемый интерфейс сетевых системных вызовов (socket(), bind(), recvfrom(), sendto() и т.д.) в операционной системе UNIX может применяться и для других стеков протоколов (и для протоколов, лежащих ниже транспортного уровня).

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

  Второй параметр служит для задания вида интерфейса работы с сокетом — будет это потоковый сокет, сокет для работы с датаграммами или какой-либо иной. Третий параметр указывает протокол для заданного типа интерфейса. В стеке протоколов TCP/IP существует только один протокол для потоковых сокетов — TCP и только один протокол для датаграммных сокетов — UDP, поэтому для транспортных протоколов TCP/IP третий параметр игнорируется.

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

  Для транспортных протоколов TCP/IP мы всегда в качестве первого параметра будем указывать предопределенную константу AF_INET (Addressfamily — Internet) или ее синоним PF_INET (Protocolfamily — Internet).

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

  Подобные документы

  Характеристика модели клиент-сервер как технологии взаимодействия в информационной сети. Разработка и описание алгоритмов работы приложений на платформе Win32 в среде Microsoft Visual Studio, использующих для межпроцессного взаимодействия сокеты.

  курсовая работа [544,6 K], добавлен 02.06.2014

  Изучение сущности и основных функций программного интерфейса для обеспечения обмена данными между процессами, который называется сокет. Сокеты и UNIX. Атрибуты и именование сокета. Установка соединения (сервер, клиент). Обмен данными. Закрытие сокета.

  презентация [99,1 K], добавлен 12.05.2013

  Варианты топологии одноранговой вычислительной сети, принцип работы распределенных пиринговых сетей. Использование в крупных сетях модели «клиент-сервер». Характеристика операционных систем с сетевыми функциями, многопроцессорная обработка информации.

  творческая работа [51,8 K], добавлен 26.12.2011

  Организация связи между электронными устройствами. Коммуникационный протокол, основанный на архитектуре «клиент-сервер». Чтение флагов, дискретных входов, регистров хранения и регистров ввода. Запись регистра хранения. Обработка прерываний и запроса.

  курсовая работа [1,4 M], добавлен 07.07.2011

  Разработка приложений на платформе Win32 для исследования взаимодействия между процессами через отображение файла в память. Модель приложений «клиент — сервер». Описание алгоритма работы программы-клиента и программы-сервера. Результаты работы приложений.

  курсовая работа [869,3 K], добавлен 18.05.2014

  Особенности программной архитектуры клиент-сервер, взаимодействие серверов и пользователей сети Интернет согласно сетевым протоколам. Классификация служб по выполняемым функциям: доступ к гипертекстовому контенту, файлам, проведение телеконференций.

  реферат [31,5 K], добавлен 12.07.2015

  Общее понятие о пакете «java.net». Логическая структура соединений через сокеты. Создание объекта Socket, соединение между узлами Internet. Способы создания потока. Алгоритм работы системы клиент-сервер. Листинг ServerForm.java, запуск подпроцесса.

  лабораторная работа [174,6 K], добавлен 27.11.2013

  Читайте также:

    

  • Прекрасное в жизни и искусстве реферат

    

  • Медициналық интроскопияның негізгі реферат

    

  • Эпидемиологическое значение почвы реферат

    

  • Образ собаки в литературе xx века реферат

    

  • Заболевание нервной системы у пожилых людей реферат