Проект ???????. 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-адрес клиента Никнейм Хэш-пароль */