отказоустойчивой. ВАЖНО!

Проект ???????.
1) Общее описание:
Проект является клиент-серверным приложением. Причем должна быть возможность
соединения большого кол-ва клиентов. Проект состоит из нескольких частей –
см.раздел архитектура.
Готовый продукт(v1.0) должен обеспечивать:
- регистрацию пользователей на сервере.
- хранение данных пользователя в БД
- аутентификацию пользователя на сервере
- соединение клиентских приложений и дальнейшее их взаимодействие(передачу
данных различного типа в онлайн режиме).
- возможность создание чатов(когда клиентских приложений в соединении >2)
- систему удаленного мониторинга(сбор статистики) сервера
- систему удаленного управления сервером
В конечном счете пользователь, установивший приложение, посредством
графического интерфейса(см. Раздел «Графический интерфейс пользователя»)
должен иметь возможность обмена данными(текст, файлы, видео, аудио..).
2) Разработка. Технические вопросы.
- В процессе разработки проекта должна быть возможность «внедрения» новых
программистов, для этого задачи по реализации/проектированию предлагается
разделять между составом команды, при этом учитывать личные навыки и знания.
- Весь код предлагается хранить на домашнем сервере. Для управления проектом
используется Subversion(SVN).
- Тестовый сервер устанавливается по желанию разработчика – можно установить на
своем ПК или попросить у (Стаса) сделать персональный туннель до его сервера.
- Кодинг-стайл. Файл с кодинг-стайлом будет выложен в папку wiki проекта.
Необходимо его соблюдать – это удобно красиво. При несоблюдении – разработчику
придется делать рефакторинг.
- Проект будет реализовываться на языке C/C++. Будут использованы стандартная
библиотека шаблонов(STL), BOOST, sock, QT и многое другое. Очень полезны знания
ОС UNIX. Следует отметить, что для участия в проекте необходими уверенные навыки
программирования на С++(+САМОСТОЯТЕЛЬНАЯ реализация лаб.раб.) и знание STL.
- папка wiki. В эту папку необходимо складывать все полезные ресурсы: описание
библиотек, структура проекта и т.д..
- перед commit’ом на ветку предлагается устраивать review кода. Проводится
следующим образом: разработчик делает патч и выкладывает его в заранее
обговоренное место(либо посылает по почте). Ревьювер должен просмотреть код на
«правильность» архитектуры, ошибки, опечатки. По необходимости можно применить
патч. Если у ревьювера есть какие либо претензии к коду /проекту – это необходимо
обсудить.
- инструменты. Тут никакие ограничения не вводятся.
Рекомендации: на платформе UNIX рекомендуется использовать Eclipse, kdevelop, а
для самых хардкорщиков VIM. На платформе windows – MVS10, qt creator.
Предпочтительнее конечно qt creator, по той причине что в MVS придется настраивать
qt_mvs_addin – это геморно.
- все добавленные библиотеки также загружать в репозиторий в специально
отведенную папку.
- http://blog.nsws.ru/rabota-s-git-dlya-nachinayushhix.html
2) Общая архитектура:
Структуру проекта можно разделить на три основный части, это серверная
часть(SERVER_PART),
клиентская
часть(CLIENT_PART)
и
внешний
контроллер(EXT_CONTROLLER) – подробное описание всех частей см.ниже. В свою
очередь каждая часть может быть разделена. Клиентская часть – это клиенты для
платформ windows и unix. Серверная часть – это модуль управления базой данных и
главный модуль управления(???может быть его тоже разделить на части). Внешний
контроллер – это отдельный модуль, тут разделение не требуется.
CLIENT_PART
win_clients
SERVER_PART
DATA_BASE_MANAG
ER
unix_clients
SERVER_MANAGER
EXT_CONTROLLER
3) Общее представление модулей.
SERVER_PART(серверная часть): серверная часть состоит из двух модулей(реализуем
ввиде сервисов). Необходимо проектировать серверную часть так, чтобы в
дальнейшем была возможность легко адаптировать ее работу под кластер.
SERVER_MANAGER: основной сервис. Нужен для установления соединения между
клиентами. Задачи:
- взаимодействие с клиентом (см. протокол взаимодействия с клиентом)
- взаимодействие с базой данных (см. протокол взаимодействия с базой данных)
- управление работой клиентов
Работу этого сервиса надо установить таким образом, чтобы при непосредственном
общении клиентов он сам (сервер) не учавствовал. Т.е. SERVER_MANAGER отвечает за
установку соединения между клиентами, далее вся работа ложиться на CLIENT’a.
Работа этого модуля должна быть максимально быстрой и отказоустойчивой.
ВАЖНО! – не выносить найстройки в конфигурационный файл.
(необходимо продумать логику установки соединения – ожидающий сокет,
очередь....)
DATA_BASE_MANAGER: сервис управления базой данных. Устанавливает соединение с
SERVER_MANAGER. Задачи:
- запись и хранение данных
- автоматическая очистка устаревших данных
В общем: нужен для выделения работы с БД. Т.е. SERVER_MANAGER дает команду на
получение данных, DB_MANAGER формирует запрос, затем возвращает результат
главному приложению.
Обмен данными между модулями серверной части предлагается реализовывать с
помощью shared_memory(ОБСУДИТЬ!!!).
В качестве СУБД предлагается использовать postgresql. Модуль должен обладать
высокой отказоустойчивостью.
STATUS_MANAGER: root-клиент. GUI для управления и наблюдения работы серверной
части (см. протокол взаимодействия с SERVER_MANAGER). Задачи:
- сбор и отображение статистики
- ручное управление базой данных
- ручное управление работой SERVER_MANAGER
Основной целью является – круглосуточное наблюдения за работой сервера.
Необходимо собрать всю необходимую статистику для вывода. ВАЖНО! – работа этого
модуля никак не должна сказываться на работе SERVER_MANAGERA, кроме случаев
управления.
Необходимо придумать команды управления и данные для сбора статистики.
Работа этого модуля менее приоритетна, чем другие модули. По этой причине первый
этап реализации сервиса начать по выпуску продукта v1.0.
/*
Протокол взаимодействия с клиентом.
1) Регистрация аккаунта.
Необходимые данные от пользователя: Никнэйм, пароль.
Никнейм и пароль отправляется серверу. Сервер передает данные менеджеру базы
данных. Менеджер БД проверяет уникальность никнейма пользователя, затем либо
создает пользователю уникальный id и заносит запись в таблицу БД, возвращая
серверу статус OK, либо возвращает статус FAIL. Сервер передает статус запроса
клиенту. В зависимости от него пользователь может либо залогиниться, либо
повторить попытку регистрации.
UPDATE: пароль пользователя не передавать серверу. Устроить его передачу и
хранение следующим образом: перед отправкой пароля серверу, захэшировать его.
Серверу же отправить захешированные данные и сравнение в таблице БД проводить
по хешированным данным (таким же способом хранятся пароли в UNIX).
2) Аутентификация.
Необходимые данные: Никнейм, пароль.
Захэшированный пароль и никнейм отправляются серверу.
Пакет:
Версия клиента
Ip-адрес клиента
Никнейм
Хэш-пароль
*/