ICQCorp
Навигатор О проекте Новости Ссылки Установка ФАКи Скриншоты Благодарности Документы PostgreSQL Скачать Об авторе Гостевая книга Russian English Проект IServerd

--- Архитектура сервера IServerd.

Изначально уже при общем проектировании стало ясно, что в большинстве функций обработки пакетов ICQ в IServerd будут использоваться блокирующие функции, с достаточно большим временем блокирования (запросы к базе данных, сетевые функции и т.п.). Я решил отказаться от модели нитей (threads) и использовал разделение процессов по функциям.

На настоящий момент используется 7 типов процессов. Главным процессом является "Socket processor" или просто SP, который прослушивает порт ICQ и складывает все пакеты в очередь, которая затем разбирается процессами обработки пакетов (packet processors или PP). Кроме этого SP также следит за остальными процессами и контролирует их работу. При аварийном завершении какого-либо процесса запускается его новая копия. Для предотвращения остановки работы сервера из-за "мертвой" блокировки в базе данных SP содержит встроенный watchdog, который при обнаружении зависания производит рестарт дочерних процессов. Если сервер баз данных внезапно отключится, все процессы завершаются и затем при включении сервера баз данных работа возобновится.

Текущая версия SP прослушивает два сокета - главный udp и wwp. WWP сокет служит для отправки сообщений через WEB. Это unix domain socket (UDS), который находится в каталоге /tmp.

Коммуникации между процессами осуществляются при помощи unix domain sockets. SP складывает все приходящие пакеты в очередь, которая разбирается процессами PP (они используют IPC семафоры для синхронизации). Ответные пакеты, на которые требуется получить подтверждение отправляются в очередь, которая разбирается процессом EPP (event packet processor). Этот процесс при получении пакета, заносит запись о нем в буфер, а сам пакет отправляет клиенту. Если по истечении времени, заданного в конфигурационном файле от клиента не пришло подтверждение о получении пакета производится его повторная посылка. Число попыток также указывается в конфигурационном файле соответствующего протокола.

При подключении/отключении пользователя PP после обработки пакета отправляет через UDS сигнал процессу EUP (event user processor). Процесс EUP при старте считывает таблицу подключенных пользователей из базы данных и проверяет каждую запись. Устаревшие записи удаляются из таблицы, а остальные заносятся в кэш процесса. Во время работы EUP по сигналам ETP (event timer processor) проверяется кэш процесса и пользователи с устаревшими записями переводятся в режим offline. PP при обнаружении пакета ping отсылает уведомление EUP, а тот в свою очередь обновляет запись в кэше и таблице сервера баз данных.

При обнаружении перегрузки сервера запускается временный процесс BP, который на все пакеты в очереди отсылает пакет "server busy" и таким способом разгружает очередь. Его время жизни ограничено и равно 60 секунд.

Процесс ETP, упомянутый выше, генерирует "пульс", чтобы синхронизировать работу event процессов. Второй его функцией является выполнение запланированных переодических операции вроде вакуумизации базы данных и проверки верности кэша пользователей.



IServerd architecture



В приведенном выше рисунке показаны связи между процессами, а также их связи с сервером баз данных. В настоящее версии реализованы только UDP протоколы V3 и V5 Mirabilis, которые работают по UDP протоколу. В будущем при реализации протокола V7 будет введена дополнительная схема обработки TCP соединений. Постребуется также изменить формат пакетов во входящей очереди (ввести дополнительные поля, для идентификации принадлежности пакета к соответствующему сокету).

На рисунке также имеется не упомянутый мною процесс DP (defragmenter process). Он служит для дефрагментации пакетов. Фрагментация пакетов используется в протоколе V3 для пересылки больших сообщений. Фрагменты пакетов при пересылаются через соответствющий UDS в DP процесс и записываются в базу данных в соответствующую таблицу. После записи каждого пакета производится попытка сборки. Если она удается - пакет записывается во входящую очередь и удаляется из таблицы. Процесс ETP через определенное число секунд, заданное в конфигурационном файле, производит очистку таблциы фрагментов (удаляются только устаревшие записи).

При включении опции "enable actions" PP будут посылать уведомления о различных событиях процессу AP (actions processor), который затем выполняет действия, привязанные к этому событию в конфигурационном файле actions.conf

Все вышеупомянутые UDS (кроме wwp) находятся в каталоге var сервера (он задается в конфигурационном файле). К имени каждого UDS добавляется через точку номер сокета UDP который прослушивается сервером. Т.е. для сервера, прослушивающего порт 4000 в каталоге var будут следующие файлы: pipe_epp.4000, pipe_eup.4000, pipe_frg.4000, pipe_inc.4000, pipe_out.4000, pipe_act.4000.

About  ] Install  ] Credits  ] Screens  ] Postgres  ] Download  ]
News  ] FAQs  ] Author  ] Links  ] Documents  ] Guestbook  ]
Webmaster
A.V.Shutko