2. 1 Клиент-серверная модель взаимодействия



Скачать 54.47 Kb.
Дата31.12.2012
Размер54.47 Kb.
ТипДокументы
2 Паттерн поведения Gen_Server (Generic Server)
Данный раздел представляет собой обзор серверной части клиент-серверного взаимодействия, реализуемого на основе OTP.

Детальное описание интерфейса обобщённого сервера и callback-функций, предоставляемых им для реализации, приведено в описании модуля gen_server ССЫЛКА.
2.1 Клиент-серверная модель взаимодействия
В рамках клиент-серверной модели существует один сервер и произвольное число клиентов. Эта модель в основном используется при проектировании управления ресурсами, когда нескольким клиентам требуется доступ к общему ресурсу. Сервер хранит этот ресурс и управляет доступом к нему.
clientserver.gif


2.2 Пример
Пример простого сервера, написанного на чистом Erlang (без использования OTP) приведён во введении (ССЫЛКА). Используя шаблон поведения gen_server, описанный в одноимённом модуле, и реализуя callback часть сервера, получим:
-module(ch3).

-behaviour(gen_server).
-export([start_link/0]).

-export([alloc/0, free/1]).

-export([init/1, handle_call/3, handle_cast/2]).
start_link() ->

gen_server:start_link({local, ch3}, ch3, [], []).
alloc() ->

gen_server:call(ch3, alloc).
free(Ch) ->

gen_server:cast(ch3, {free, Ch}).
init(_Args) ->

{ok, channels()}.
handle_call(alloc, _From, Chs) ->

{Ch, Chs2} = alloc(Chs),

{reply, Ch, Chs2}.
handle_cast({free, Ch}, Chs) ->

Chs2 = free(Ch, Chs),

{noreply, Chs2}.
2.3 Запуск Gen_Server
В предыдущем примере функцией запуска gen_server является функция ch3:start_link():
start_link() ->

gen_server:start_link({local, ch3}, ch3, [], []) => {ok, Pid}
Функуия start_link производит вызов функции gen_server:start_link/4, которая порождает новый процесс и связывает его с gen_server’ом.


  • Первый аргумент - {local, ch3} – определяет имя сервера. В нашем случае сервер будет локально зарегистрирован под именем ch3.

Если имя будет опущено, то gen_server не будет зарегистрирован. Вместо имени будет использоваться идентификатор процесса. В качестве имени также может быть передан кортеж {global, Name}, при этом сервер будет зарегистрирован с помощью функции global:register_name/2.

  • Второй аргумент - ch3 – имя callback-модуля, в котором расположены callback-функции, реализованные нами.

В нашем случае, интерфейсные функции (start_link, alloc и free) и callback- функции (init, handle_call и handle_cast) расположены в одном модуле. Это достаточно обычная ситуация, поскольку удобно размещать код, связанный с процессом, в одном модуле.


  • Третий аргумент - [] - терм, который передаётся в качестве параметра callback-функции init. В нашем случае init не требуется никаких входных данных, поэтому мы передаём третьим аргументом пустой список.

  • Четвёртый аргумент - [] – список опций. Список доступных опций приводится в описании модуля gen_server(3) ССЫЛКА.


В случае успешной регистрации созданный серверный процесс вызывает callback-функцию ch3:init([]). Предполагается, что init вернёт кортеж {ok, State}, где State – внутреннее состояние сервера. В нашем случае таким состоянием является множество доступных соединений - channels.
init(_Args) ->

{ok, channels()}.
Вызов функции gen_server:start_link является синхронным. Управление не будет возвращено до тех пор, пока не будет завершена инициализация сервера, и он не будет готов принимать входящие запросы.

Функция gen_server:start_link должна быть использована, при создании сервера как части дерева супервизоров, в этом случае сервер должен быть запущен супервизором. Существует и другая функция - gen_server:start - для запуска автономного, т.е. не являющегося частью дерева супервизоров сервера.
2.4 Синхронный вызов – Call
Возможность посылки синхронного запроса alloc() серверу реализована с помощью функции gen_server:call/2:
alloc() ->

gen_server:call(ch3, alloc).
ch3 – имя сервера (должно совпадать с именем, под которым сервер был запущен).

alloc – само значение(«текст») запроса.
Запрос превращается в сообщение и посылается серверу. При получении этого сообщения gen_server вызывает функцию handle_call(Request, From, State). Предполагается, что эта функция вернёт кортеж {reply, Reply, State1}. Где Reply – ответ, передаваемый клиенту, а State1 – новое внутренне состояние сервера.
handle_call(alloc, _From, Chs) ->

{Ch, Chs2} = alloc(Chs),

{reply, Ch, Chs2}.
В нашем случае ответом является выделенное соединение, а новым состоянием сервера – Chs2 - список оставшихся, незанятых соединений.
Таким образом, вызов функции ch3:alloc() возвращает выделенное соединение, обновляет список доступных соединений. Затем сервер продолжает ожидать поступления новых запросов.
2.5 Асинхронный вызов – Cast
Возможность асинхронного запроса free(Ch)реализована с помощью функции gen_server:cast/2:
free(Ch) ->

gen_server:cast(ch3, {free, Ch}).
ch3 – имя сервера.

{free, Ch} – «текст» запроса.
Запрос превращается в сообщение и посылается серверу. Сразу после этого функция free(Ch) возвращает результат ok и выполнение клиентского процесса продолжается.
При получении сообщения, сервер вызывает функцию handle_cast(Request, State). Предполагается, что эта функция вернёт кортеж {noreply, State1}. Где State1 – новое состояние сервера.
handle_call({free, Ch}, Chs) ->

Chs2 = free(Ch, Chs),

{noreply, Chs2}.
В нашем случае новым состоянием является обновлённый список доступных соединений Chs2. Теперь сервер готов к обработке новых запросов.
2.6. Остановка
2.6.1 Сервер – часть дерева супервизоров
Если сервер является частью дерева супервизоров, то необходимость в отдельной функции завершения работы отсутствует, поскольку сервер будет автоматически остановлен своим супервизором. Конкретный способ остановки определяется стратегией завершения работы потомка супервизора ССЫЛКА.

Если необходимо произвести некоторую очистку перед завершением работы, то стратегия завершения должна быть определена как значение тайм-аута, кроме того, у процесса gen_server должен быть установлен флаг обработки сигнала exit. Установку флага можно осуществить в функции init.
init(Args) ->

...,

process_flag(trap_exit, true),

...,

{ok, State}.
...
При получении команды на завершение работы, сервер вызывает callback-функцию terminate(shutdown, State):
terminate(shutdown, State) ->

..code for cleaning up here..

ok.
2.6.2 Автономный сервер
Если сервер не является частью дерева супервизоров, то функция завершения работы может оказаться полезной, например:

...

export([stop/0]).

...
stop() ->

gen_server:cast(ch3, stop).

...
handle_cast(stop, State) ->

{stop, normal, State};

handle_cast({free, Ch}, State) ->

....
...
terminate(normal, State) ->

ok.
В данном примере callback-функция, обрабатывающая запрос stop, возвращает кортеж {stop, normal, State1}, где значение normal говорит о корректном завершении работы, а State1 содержит новое состояние сервера. Это позволит gen_server’у вызвать функцию terminate(normal,State1)и корректно завершить исполнение.
2.7 Перехват других сообщений
Если сервер может получать другие сообщения, отличные от вызовов-запросов, то для их обработки требуется реализовать callback-функцию handle_info(Info, State). Примером таких сообщений может служить сообщение exit, получаемое процессом, в случае если он связан с другими процессами и обрабатывает сигнал exit (последнее устанавливается с помощью специального флага).
handle_info({'EXIT', Pid, Reason}, State) ->

..code to handle exits here..

{noreply, State1}.

Похожие:

2. 1 Клиент-серверная модель взаимодействия iconAjax расшифровывается как Asynchronous JavaScript and xml
Однако так как эта концепция вносит некоторые изменения в модель взаимодействия клиент-сервер и открывает новые возможности по написанию...
2. 1 Клиент-серверная модель взаимодействия iconКраткий обзор для sql server 2008 предусмотрены три модели лицензирования: Серверная лицензия плюс лицензии
Серверная лицензия плюс лицензии клиентского доступа на устройство. Требуется лицензия для компьютера под управлением серверного...
2. 1 Клиент-серверная модель взаимодействия iconС. 28-30. Информационная модель синхронного взаимодействия сложных систем
Целью нашей работы является построение математической модели взаимодействия сложных систем. Для этого мы воспользовались информационными...
2. 1 Клиент-серверная модель взаимодействия iconПодпроект Модель сетевого взаимодействия участников образовательного процесса, реализуемая с помощью технологий Веб Проекта «Совершенствование учительского корпуса
Модель сетевого взаимодействия участников образовательного процесса, реализуемая с помощью технологий Веб 0
2. 1 Клиент-серверная модель взаимодействия iconЗадача распределенной обработки данных. Области применения
Различные типы сетей. Lan и wan сети. Классификация и сравнительная характеристика различных типов сетей. Основные модели взаимодействия...
2. 1 Клиент-серверная модель взаимодействия iconРабота в системе «Банк-Интернет-Клиент» через резервный канал связи
«Электронные расчеты» «Система Банк-Интернет-Клиент»- «Вход в систему «Банк-Интернет-Клиент»
2. 1 Клиент-серверная модель взаимодействия iconМодель структуры интеллекта Г. Айзенка. 1 Модель структуры интеллекта Дж. Гилфорда. 2 Исследования социального интеллекта отечественными психологами. 4 Библиография 8
Социальный интеллект – способность правильно понимать поведение людей. Эта способность необходима для эффективного межличностного...
2. 1 Клиент-серверная модель взаимодействия iconКомплексная модель взаимодействия власти, бизнеса и общественных организаций в стратегии развития региона

2. 1 Клиент-серверная модель взаимодействия iconЛабораторная работа №4 Использование xml и среды Axis2 для создания клиент-сервисного взаимодействия
Служебная информация документа xml заключается в теги. Первый тег описывает версию xml
2. 1 Клиент-серверная модель взаимодействия iconИнструкция пользователя 2 1Окно «Настройки» 2 2Окно «rss клиент»
Программа – bit torrent клиент (как uTorrent ), с дополнительной возможностью поиска, и скачивания контента с сайта rutracker org...
Разместите кнопку на своём сайте:
ru.convdocs.org


База данных защищена авторским правом ©ru.convdocs.org 2016
обратиться к администрации
ru.convdocs.org