Лето не
самое лучшее время для разработки проектов – море, солнце, но я все – таки продвигаюсь
потихоньку к намеченной цели!
Тестирование
игры идет полным ходом, вносятся правки в баланс, в целом подход описанный в одиннадцатой
части себя оправдал. После пары полных тестов внеслись небольшие правки, я
думаю скорее всего это будет конечные изменения в ценовой политике.
Изначально
игра задумывалась как проба сил, а также плацдарм на будущее, а что это за
плацдарм если не собирать данные из игры?! Гугл аналитика в этом плане конечно
хороший помощник, но хочется, что нить большего. В приложение «Слова любимым» для
сбора статистики по сообщением и как следствии для их ранжирования используется
HTTP запросы, а
данные хранятся в MSSQL, почему именно так? Мне на С# писать удобно, а это неплохое
решения для этого. В целом для работы мне достаточно небольшого хостинга, но за
1.5 года работы приложения, набралось 2.5 миллиона записей, это не много, но
размер бд в моей хостинг компании ограничен и край уже близок! Все экскременты
с установкой на VPS базы
данных MSSQL приводили к не очень приятным результатам – нужно больше 5 000 руб. в
месяца для тоже производительности, что и на хостинге! Происходит это из-за
того, что N площадок виртуального хостинга имеют свои БД на отдельном сервере, очень
производительном! Толи у меня соседи хорошие, толи MSSQL база данных не пользуется спросом, а
ограничения не особо сильные, я чувствую себя там довольно вольготно, а вот с
переездом сложно.
Рассказав о
своей проблеме друзьям, мне посоветовали посмотреть в сторону In-Memory Data Base (IMDB) и NoSql решений. Производительность IMDB я думаю мне пока не нужна, а вот о NoSql решениях я был довольно сильно
наслышан, но никогда не использовал. Выбор я решил остановить на MongoDB. Почитав немного, я обрадовался, что
написаны драйверы для работы с ней на C# и можно использовать Linq. Выбор сделан, осталось проверить,
как она работает, для этого я написал тест который создает базу данных похожу
на ту, которая используется для статистики сообщений, делает выборку по ней и
обновления записей, в целом результат меня более чем порадовал, есть свои особенности,
но я думаю изучить данную технологию точно стоит. И так, раз уж пошла такая
пьянка, а моей мечтой по-прежнему остается разработка онлайн мморпг, да еще
чтобы в ней можно было грабить караваны, то без хорошего сервера далеко не уедешь
:-D
Так я решил
заняться разработкой серверной части.
На сервер возложены функции: регистрация
игроков, авторизация, сбор статистики, выдача по запросу рейтинга. Также
необходимы средства мониторинга. Язык разработки C#. В качестве протокола передачи данных будет
использоваться UDP, база данных - MongoDB. Задача я думаю более чем интересная.
Опыта в создании данных вещей у меня нету, но откуда его взять если не пробовать?!
Как я себе
вижу данное программное решение, основные тезисы:
- Внутри главного потока бесконечный цикл, время каждого цикла фиксированное, те если он выполниться быстрее чем необходимо, он будет ожидать остаток времени. Фиксированный серверный тик.
- Поток на чтение. Слушаем определенный порт, из полученных данных формируем задачу и отправляем в очередь.
- В начале каждого серверного тика забираем полученные задачи, выполняем их. Если количество задач превышает некоторые порог, то будет принято на обработки только фиксированное количество задач, для возможности выполнения их, в единицу времени, отведенную на тик.
- Задачи требующие подтверждения отправляются в очередь на подтверждение. По истечению времени, если подтверждение не получено, выполняются повторно, если количество операций превышает определенный рубеж они снимаются.
- Все расчеты выполняются в серверных тиках.
- Отправка данных создает новый поток.
- После авторизации создается сессия на ~10 минут. Все операции с игроком происходят в рамке этой сессии. По истечении времени сессия протухает – требуется повторная авторизация.
- Для проверки целостности переданного пакета будет использоваться алгоритм CRC16. Некорректные данные будут игнорироваться.
- Для шифрования данных внутри пакета будет использоваться AES.
- Сервер должен без проседания производительности держать >1000 сессий.
- Мусора из сети должен игнорироваться.
- Большие данные делятся на несколько пакетов.
- Пользователи, чья активность считается не нормальной попадают в черный список на ~10 минут, все сообщения от них будут игнорироваться.
- Сервер должен писать логи по активности клиентов. А также все вызванные ошибки.
- Необходимо написать тесты на корректность создания пакетов, задач, прием и обработку пакетов. Время выполнения задач.
- Нагрузочный тест, для проверки максимального количества сессий.
Список
получился не маленький, но и то не полный, я постараюсь его дополнять в порядке
разработки. Если у кого есть идеи или пожелания, милости прошу в комментарии
или на почту.
Комментариев нет:
Отправить комментарий