Использование в режиме дейтаграмм

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

Сервер:
- создает сокет;
- связывает сокет-адрес с сервисной программой: "binding" (операция необходима только в случае, если процесс должен получить данные);
- считывает или осуществляет запись на сокет.

4.3.3. Рабочие характеристики

Присвоение номеров портов

Зарезервировано определенное число номеров; это номера в диапазоне от 1 до 1023, отведенные для стандартных служб. Для сервера номер порта либо закреплен в программном коде, либо считывается в файле /etc/services, либо присваивается системой в момент bind (). Для клиента номер порта либо зафиксирован в его коде, либо считывается из файла /etc/services, либо присваивается системой в момент connect (). Если номер порта сервера хранится в /etc/services, файл /etc /services клиента должен содержать идентичный номер, что приводит к возникновению проблемы соответствия. Можно дать системе возможность выбора номера порта для сервера и восстановить этот номер в процессе-клиенте. Для этого можно использовать функции popen () или rexec (). Пример такого решения мы увидим в разделе 4.3.5. Другое решение состоит в том, что в программах фиксируется номер порта, идентичный для клиента и для сервера, при условии, что этот номер не используется уже другой сервисной программой. Проверить, что был ли присвоен номер, можно справив-шись в таблице /etc/services (номера портов, установленных для определенного числа служб) и в результате выполнения команды rpcinfo -p (номера портов, динамически присвоенных серверам RPC).

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

Считывание с сокета с установлением логического (виртуального) соединения обладает следующей особенностью: примитив возвращает результат после считывания, по крайней мере, одного байта; в результате этого, число считанных байтов часто меньше требуемого числа. Следовательно, необходимо зациклить примитив считывания, чтобы добиться продолжения... Точнее, вот что возвращает вызов примитива read () (или recv (), или recvfrom ()):

-1: если соединение разорвано или не существует;

>0: было получено определенное число байтов; необходимо организовать цикл считывания для продолжения работы (конечно же, нет необходимости в организации цикла, если ожидаемое количество байтов уже получено);

0: удаленная программа выполнила close (), на чем и остановилась. Функция записи возвращает результат после того, как буфер выходных данных быдет передан через TCP. Программа предупреждается о возможной ошибке сигналом SIGPIPE, о котором речь пойдет далее.

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

Управление сигналами

С сокетами связаны 3 сигнала:

- SIGIO: указывает на то, что сокет готов к асинхронному вводу-выводу. Сигнал посылается процессу или группе процессов, связанных с сигналом;

- SIGURG: указывает на то, что на сокете получены экспресс-данные. Посылается процессу или группе процессов, связанных с сигналом;

- SIGPIPE: указывает на то, что запись на сокете более невозможна. Посылается процессу, связанному с сокетом. Более подробно использование данных сигналов объясняется в нижеследующих разделах.

Управление ошибками

Как уже было указано, сигналы об ошибках реализуются следующим образом:

- read () возвращает ноль, если удаленный процесс разрушен или -1, если прервана связь по сети;

- write () вызывает посылку сигнала SIGPIPE, если удаленный процесс разрушен или если связь по сети прервана.

Для проверки работоспособности удаленного процесса можно добавить управление с помощью реле времени (темпоризатора) по вызовам read () или write (). Возможно, что read () никогда не кончит свою работу, если удаленная программа зациклилась, или что вызов займет слишком много времени, если удаленная машина сильно загружена. Возможен аварийный останов программы-клиента. Сервер в этом случае должен контролировать присутствие клиента. Следует установить опцию SO_KEEPALIVE, которую мы рассмотрим в разделе об определении параметров сокетов. Дополнительный контроль можно осуществить следующим образом: сервер периодически осуществляет запись байта в контрольный сокет. Таким образом, если клиента больше нет, будет обнаружена ошибка SIGPIPE и сервер остановится. Пример использования этого механизма приведен в главе 10 "RPC".

Определение параметров сокета

Наиболее интересными опциями являются:

- TCP_NODELAY: запрещает хранение данных в буферах TCP;

- SO_ERROR: пересылает значение переменной so_error, определяемой в файле <sys/socketvar.h>;

- SO_KEEPALIVE: периодическая передача контрольных сообщений насокет в режиме установления соединения.

Если один из процессов не отвечает, соединение считается прерванным и в переменной so_error возвращается ошибка ETIMEDOUT (см. опцию SO_ERROR); - SO_RCVBUF и SO_SNDBUF: определяет размер буферов TCP. Характеристики можно улучшить, взяв буферы большего размера;

- SO_REUSEADDR: позволяет повторно использовать уже использованный сокет-адрес (в частности, номер порта).

Сокеты представляют собой интерфейс входа в сеть - надстройку транспортной службы. Термин "сокет" обозначает одновременно библиотеку функций и точку входа в канал связи, то есть дескриптор, полученный посредством примитива socket (). Программирование сокетов заключается в комбинировании определенного числа примитивов для считывания или записи потока байтов или сообщений. Сокеты позволяют входить в сеть, как в файл. Этот интерфейс гибкий, но достаточно низкого уровня. Существуют два режима его применения, в зависимости от использования сокетов типа SOCK_STREAM или SOCK_DGRAM. В первом случае устанавливается соединение с TCP, во втором, работа идет с UDP в режиме дейтаграмм. Для упрощения программирования сокетов можно создать библиотеку более высокого уровня, позволяющего передавать простые типы данных (целые, с плавающей запятой, символы, массивы...). Можно обеспечить доступ к базе данных посредством программных продуктов, использующих сокеты (программные средства SQL), причем применение этих продуктов прозрачно для пользователя.

23. Архітектура ГІІ. Визначення. Склад поняття. Модельне подання. Промислова модель. Структурна модель. Функціональна модель. Модель реалізації.

Глобальна інформаційна інфраструктура – складне структурне утворення. Хоча в основі її лежать мережі передачі повідомлень, численні і різноманітні послуги і додатки, що формуються за допомогою цих мереж, вони вимагають утворення багатьох видів служб, платформ і механізмів для цих послуг підтримки (рис. 1.6. «Загальна архітектура ГІІ»). Розробляються моделі, конфігурації ГІІ, які враховують нові ролі користувачів ГІІ і нові внутрішні інфраструктурні ролі ГІІ.

Метою корпоративної (промислової) моделі є ідентифікація інтерфейсів, що мають найбільше комерційне значення. Одним з центральних понять при побудові даної моделі служить поняття ролі.

Ролі виконуються учасниками взаємодії і мають певний час життя. Ролі мають інтерфейс. Вони приймають від постачальників сервіс або послугу ("товар"), змінюють її (або додають додатковими властивостями) і передають її далі своїм користувачам, утворюючи, таким чином, якийсь ланцюжок, що досягає кінцевого споживача (рис. 4.1).

Визначення термінів промислової моделі:

- роль – це певна ділова активність в послідовності створення кінцевого продукту. Роль обмежена мінімально необхідними масштабами ділової активності, що дозволяє їй існувати незалежно у даній галузі промисловості так, щоб для кожного взаємозв'язку між ролями було визначено місце на ринку;

- послідовність створення кінцевого продукту – це сукупність ролей, задіяних в створенні кінцевого товару (послуги) і об'єднаних у так зване "дерево" ролей;

- структурна роль - роль в основному промисловому ланцюзі, яка має деякий вироблюваний продукт (послугу) і пов'язана з економічною або діловою активністю в області інформаційних послуг і додатків;

- інфраструктурна роль - представляє елемент ланцюга, головним чином пов'язаного з повторним використанням компонентів;

- учасник - організація або індивідуум, що виконує одну або декілька ролей, може бути комерційною, урядовою або неурядовою організацією;

- взаємовідношення між ролями - виникає при з'єднанні двох ролей в ланцюзі з метою передачі послуги (товару);

- горизонтальні взаємини - стосунки між двома сусідніми ролями, що знаходяться в одному ланцюзі (структурне відношення);

- вертикальні взаємини - стосунки між двома ролями, що знаходяться в різних ланцюгах;

- сегмент – складова частина ролі.

При даному розділенні між ролями і учасниками зрозуміло, що модель може відноситися тільки до понять ролі.

Структурні ролі відносяться до чистого виробництва продукту (послуги) і формують ланцюг від початкових даних до кінцевої послуги (рис. 4.2).

Структурні ролі інформаційної індустрії включають наступне:

- джерело інформації, що перетворює "сиру" інформацію у вигляд, зручний для використання;

- роль створення і виробництва інформації, яка одержує на її основі інформацію, що доставляється;

- роль надання інформації, що перетворює її в застосовну форму;

- роль створення і виробництва інформаційних послуг і додатків, що створює із застосовної інформації інформаційну послугу;

- роль надання інформаційних послуг, що або поширює інформаційну послугу, або розділяє її на контейнери, що сприймаються користувачем;

- роль кінцевого користувача.

У відносинах між ролями одна з них є постачальником, інша - споживачем деякого ресурсу (наприклад, інформації), що вимагає присутності також:

- ролі (manager role), що управляє, адмініструє відношення між структурними ролями;

- посередницької ролі (broker role), що бере участь у взаємодії і вибирає проміжного постачальника і споживача.

Відношення між даними ролями показано на рис. 4.3.

Інфраструктурні ролі відносяться до діяльності, яка допомагає структурним ролям обмінюватися необхідною інформацією, хоча і не повинна нічого знати про характер цього обміну, і, таким чином, надають останнім інфраструктурні послуги, товари, додатки (рис. 4.4). Структурні ролі не є частиною ГІІ.

Можна визначити деякі інфраструктурні ролі, присутні в ГІІ:

- забезпечення базових і розширених телекомунікаційних послуг і додатків (наприклад, телефонна послуга);

- забезпечення базових і розширених комерційних комунікаційних послуг і додатків (наприклад, комп'ютерна телефонія);

- забезпечення радіомовних і телевізійних послуг і додатків (широкомовні послуги);

- забезпечення послуг і додатків розподіленої обробки і зберігання інформації.

Структурна модель ГІІ (structural model). Метою структурної моделі є ідентифікація послуг і застосувань, що надаються, пропонованими ролями (рис. 4.6). Як видно з рисунка, для надання послуги роль повинна об'єднати ресурси в застосовний набір. Ресурс може надаватися іншою роллю, тобто бути додатком або послугою іншої ролі.

Визначення термінів в структурній моделі:

- послуга, що традиційно розуміється як взаємодія між компонентами системи, характеризується транзакціями між ролями, і в загальному випадку роль клієнта запрошує роль сервера про необхідну інформацію;

- додаток – сприймається подібно до послуги, з тією відмінністю, що додаток може бути використаний повторно;

- домен (область, область відповідальності, сфера, галузь) – набір сегментів у володінні учасника;

- платформа забезпечення послуги – основа надання послуги, що складається з набору сегментів, для цього необхідних, і може включати декілька доменів;

- контракт – основа угод між двома учасниками виконуючими різні ролі, що визначає порядок взаємодії між ними;

- інтерфейс послуги – засоби використання послуги учасником взаємодії, що включають аспекти міжролевих стосунків, інформаційні, обчислювальні, реалізаційні;

- сервісна компонента – компонента інтерфейсу послуги;

- сегмент – суть, загальна для корпоративного, структурного і функційного моделювання.

Структура послуг і додатків. Користувач може використовувати чисту послугу або працювати з додатком. В цьому випадку додаток використовує послугу ГІІ, але в той же час і додаток може бути реалізований в ГІІ або використовувати компоненти додатків, реалізованих в GII.

Зі свого боку ГІІ об'єднує необхідні мережні ресурси, ресурси обробки і зберігання, ресурси середнього рівня (middleware). Послуги і додатки будуються з так званих "будівельних блоків", тобто компонентів, що асоціюються з ресурсами. Надання інфраструктурних послуг залежить від рівня складності розроблених інфраструктурних ролей. До недавнього часу ці ролі були досить прості і користувачі купували компоненти додатків, але з розвитком ГІІ ці характеристики будуть доступні вже як послуга складнішої системи комунікацій і організації роботи інфраструктури інформаційної ролі ГІІ. Таким чином, виявляється тенденція переходу компонентів додатків на середній рівень (middleware).

Число можливих послуг велике, тому вводиться класифікація сервісних компонентів.

Визначаються наступні класи сервісів:

Інфраструктурні сервісні компоненти. Ці компонентів утворюють повний набір сервісних компонент ГІІ. Вони можуть реалізовувати як можливості високого рівня, так і інших розподілених ресурсів, тобто middleware і baseware.

Ролі ГІІ представляють використання компонентів користувачам ГІІ, наприклад, структурним ролям.

Сервісні компоненти середнього рівня (middleware). Компоненти в загальному випадку використовують тільки ресурси middleware і не вимагають інших розподілених ресурсів. У цей клас сервісів включаються компоненти базового рівня, розширені необхідною функційністю, що дозволяє організувати роботу інфраструктури.

Сервісні компоненти базового рівня (baseware). Компоненти діляться на компоненти базовою мережного сервісу і компоненти послуг розподіленої обробки і зберігання. Сервіс, що вимагає з'єднання однієї мережі через різні домени є сервісом базового рівня, тоді як сервіс, що вимагає з'єднання різних мереж є сервісом середнього рівня.