Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > С/С++: Кроссплатформенное программирование, Qt/Gtk+/wxWidgets > [Qt] Дипломная работа : Сетевая нарды


Автор: IKM2007 13.9.2010, 14:45
Доброго дня и всех с праздником.
Тема дипломной "Сетевая нарды". В прошлом году сделал курсовую по этой же теме, но реализовал ее только для локальной сети, то есть архитектура программы была такой, что о работе в интернете не было и речи(не было отдельного сервера, все сообщения передавались от компа к компу). Теперь надо все сделать как надо + реализовать игру с компом. 

Думаю сделать так : 
сам проект будет состоять из двух отдельных модулей: client.exe и server.exe. Весь анализ входящих/исходящих сообщении + игра с компом будет на плечах клиентской части, серверная часть будет только для того, чтобы получать сообщения и отправлять их адресату. То есть в нем будет список всех играющих пар с их данными и когда сервер получает какое-то сообщение, он смотрит от кого это сообщение, находит его в списке и отправляет то же сообщение оппоненту игрока. В серверной части также будет список тех игроков, которые ждут игры. Когда кто-то входит в сетевую игру, он может подключится к любому ждущему игроку, а также может "создать игру" и сам ждать кого-то. В общих чертах описал то, что хочу сделать. Если есть какие-то замечания, буду рад слушать.

И еще подскажите инфу, где я могу прочитать о многопоточных серверах и способах их реализации на Qt. + не помешало бы любой другой информации по теме.

Автор: Любитель 13.9.2010, 15:13
Цитата(IKM2007 @  13.9.2010,  14:45 Найти цитируемый пост)
Весь анализ входящих/исходящих сообщении + игра с компом будет на плечах клиентской части, серверная часть будет только для того, чтобы получать сообщения и отправлять их адресату

Сразу могу сказать - плохая идея. На то он и клиент, что он должен только рисовать и обрабатывать юзер экшены. В противном случае: да здравствую читеры, нету никакой централизованной статистики, проблема рассинхронизации данных (при каких-то сетевых проблемах) очень актуальна (т. к. у каждого своя копия "состояния игры"). Если есть время/возможность - лучше сделать по уму, конечно. Учитывая, что хочется иметь игру "с компьютером" - разумно продумать архитектуру выделив часть кода, отвечающую за хранение поля и обработку охдов в отдельный слой.

Вспоминается интересная статья (она больше историческая, чем техническая, но всё равно полезна) - http://habrahabr.ru/blogs/games/84543/.

Пример "чистого" сервера (без дополнительных обёрточных протоколов) AFAIR есть в самой Qt.

Автор: IKM2007 13.9.2010, 15:58
Цитата(Любитель @  13.9.2010,  15:13 Найти цитируемый пост)
Сразу могу сказать - плохая идея. На то он и клиент, что он должен только рисовать и обрабатывать юзер экшены.

Да, но подумал не нагружать сервер, он и так будет многопоточным, не будут ли задержки, если допустим одновременно будут играть 100 пар? Он будет анализировать 100 поступающих сообщении одновременно.

Цитата(Любитель @  13.9.2010,  15:13 Найти цитируемый пост)
Учитывая, что хочется иметь игру "с компьютером" - разумно продумать архитектуру выделив часть кода, отвечающую за хранение поля и обработку охдов в отдельный слой.

Не понял о чем вы. Можно поподробнее?

Автор: Любитель 13.9.2010, 16:25
Цитата(IKM2007 @  13.9.2010,  15:58 Найти цитируемый пост)
Да, но подумал не нагружать сервер, он и так будет многопоточным, не будут ли задержки, если допустим одновременно будут играть 100 пар? Он будет анализировать 100 поступающих сообщении одновременно.

Любые "серьёзные" сервера хранят всё у себя. Проблем не будет. Другое дело - насчёт многопоточности. Если у тебя будет по потоку на клиента, то это будет (с точки зрения производительности) очень плохо. Надо органиозвывать асинхронную обработку (неблокирующая работа с сокетами и вообще вводом/выводом).

Цитата(IKM2007 @  13.9.2010,  15:58 Найти цитируемый пост)
Не понял о чем вы. Можно поподробнее? 

Ну, я имел ввиду, что у тебя будет одна библиотека, где будут классы поля, игроков и т. д. С ней будет работать клиент (в случае game with computer) и сервер (в случае обычного мультиплеера).

Автор: IKM2007 13.9.2010, 16:45
Цитата(Любитель @  13.9.2010,  16:25 Найти цитируемый пост)
Надо органиозвывать асинхронную обработку (неблокирующая работа с сокетами и вообще вводом/выводом).

Что порекомендуете почитать по теме?

Цитата(Любитель @  13.9.2010,  16:25 Найти цитируемый пост)
Ну, я имел ввиду, что у тебя будет одна библиотека, где будут классы поля, игроков и т. д. С ней будет работать клиент (в случае game with computer) и сервер (в случае обычного мультиплеера). 

Вы про dll? Не знал, что их можно использовать для хранения временных данных. Что порекомендуете почитать о создании dll?

Если я вас правильно понял, то общая структура программы будет следующей:
server.exe - Принимает сообщение, анализирует у себя игру и отправляет обеим клиентам все координаты шашек, также при получении сообщения о броске костей у себя генерирует случайные числа и отправляет их обеим клиентам. То же самое касается остальной служебной переписки между клиентами(там кто-то вышел из сети, удвоил счет, сдался и т.д.). Здесь я не понял как будет происходить режим чтения? Думаю сделать два потока, один все время ждет сообщении и читает их, а другой поток асинхронно все анализирует и отправляет сообщения адресатам. Но я все это очень мутно представляю, так как никогда ничего такого не реализовал, да и с теорией не очень знаком. Поэтому буду благодарен за инфу.

server.dll - Хранятся данные для игры через сеть.

client.exe - Принимает сообщение о расположении всех шашек на экране, рисует их, отправляет сообщение о изменении местоположения шашек на экране + контролирует все передвижения шашек, то есть запрещает недопустимые ходы. Когда нажимают на кнопку бросание костей, отправляет серверу соответствующее сообщение и оба клиента принимают данные о выпавших костях. Так же и осуществляется другая служебная переписка между клиентами.

client.dll - Хранятся данные для игры с компьютером.

Автор: djamshud 13.9.2010, 17:37
Я такую поделку делал джаст фо фан. Идея была такой:

* сервер-партия обслуживает одну партию из двух участников; реализация правил игры - кидает кубики и т.д.;
* сервер-организатор хранит историю и юзерей, соединяет их т.д.;
* клиент-ИИ может быть выбран себе в соперники;
* клиент-морда позволяет выбирать себе соперников, двигать шашечки и ехать:).

Сделал большую часть, но потом надоело. Может быть когда-нибудь и доведу до ума.

* сервер-партия полностью готов;
* сервер-оргииназтор в зачатке;
* ИИ нет;
* морда на куте позволяет двигать шашечки по правилам;
* морда и клиент-партия используют общую библиотеку с реализацией большей части правил игры и сетевого протокола.

Исходники полурабочего поделия открывать не хочу, но могу помочь в конкретных вопросах.

Добавлено @ 17:39
И да. На сервере многопоточность излишняя.

Автор: Любитель 13.9.2010, 18:09
Цитата(IKM2007 @  13.9.2010,  16:45 Найти цитируемый пост)
Вы про dll? Не знал, что их можно использовать для хранения временных данных. Что порекомендуете почитать о создании dll?

Всмысле? Данные в памяти. Я имел ввиду библиотеку, где будут классы, инкапсулирующие это (хранение данных о состоянии игры и управление им).

Т. е. грубо говоря - некая библиотека core. И отдельно два приложения: server, client (ещё в идеале предусмотреть у сервера некий протокол для просмотра текущего состояния, бана игроков и т. д. - зависит от фантазии и доступном времени).

В плане сетевой архитектуры, основных проблем две:
1. Пул потоков (так как создание/уничтожение потока - операция не быстрая, делать это на каждом запросе накладно).
2. Non-blocking input/output.

И то, и другое в современном Qt есть из коробки - т. е. особых проблем не должно быть. Делать распаралеливание внутри кода обработки одного сообщения от клиента - не стоит (выиграть этим ничего не выиграешь всё равно).

Автор: IKM2007 13.9.2010, 18:39
Цитата(Любитель @  13.9.2010,  18:09 Найти цитируемый пост)
Всмысле? Данные в памяти. Я имел ввиду библиотеку, где будут классы, инкапсулирующие это (хранение данных о состоянии игры и управление им).

ааа, понял. 

Цитата(djamshud @  13.9.2010,  17:37 Найти цитируемый пост)
И да. На сервере многопоточность излишняя.

Почему? По моему должны быть как минимум два потока, один всегда ждет, второй работает.

Автор: Любитель 13.9.2010, 20:02
Цитата(IKM2007 @  13.9.2010,  18:39 Найти цитируемый пост)
Почему? По моему должны быть как минимум два потока, один всегда ждет, второй работает. 

Ну, если клиентов может быть относительно много, то нужен пул потоков (потоков 30-50, я думаю) - это 100%.

Автор: IKM2007 13.9.2010, 20:32
Цитата(Любитель @  13.9.2010,  20:02 Найти цитируемый пост)
Ну, если клиентов может быть относительно много, то нужен пул потоков (потоков 30-50, я думаю) - это 100%. 

Нет ну в реальности клиентов может быть от силы 2, так как прога будет тестироваться на локальке в кругу преподавателей, но во время защиты один из них может сказать, что проект не будет нормально работать, если игроков будет много, поэтому и хочу все сделать так, чтобы не нашли к чему придираться.
Ладно, сейчас все обсуждать думаю не имеет смысла, так как очень поверхностно все представляю. Думаю изучить инфу по теме, затем если будут вопросы, напишу в этой теме. Спасибо за быстрые ответы. +

Автор: djamshud 13.9.2010, 20:40
IKM2007, на двух можно конечно и потоки использовать, но вообще более правильный вариант организации работы с клиентами уже был озвучен. Учитесь уж сразу делать хорошо, благо пока студент - бесплатно:).

Автор: asd 14.9.2010, 08:27
Имхо, идея с реализацией на стороне клиента, не так уж плоха. Нарды - игра с полной информацией, поэтому читерить в ней не получится(кубики естественно бросает сервер) А статистику на сервере в любом случае можно вести, ходы то через него проходят. С рассинхронизацией тоже можно что-нибудь придумать(можно при каждом ходе даже посылать - для нард трафик быдет очень маленьким). Зато получим абсолютно не требовательный к ресурсам сервер.

Автор: boostcoder 17.9.2010, 16:43
Цитата(Любитель @  13.9.2010,  20:02 Найти цитируемый пост)
Ну, если клиентов может быть относительно много, то нужен пул потоков (потоков 30-50, я думаю)

что-то многовато.

в моей реализации игрушки, всего 5 потоков.
один поток обрабатывает цикл с boost::asio::ip::tcp::acceptor, проверяет IP на предмет бана, и отправляет его в пул и 4ех потоков(кол-во ядер) на основе boost::asio::io_service.
пока видел максимум из 3729 клиентов одновременно. загрузка ядер по 17 процентов.

но на qt я бы не стал такое писать.

Автор: dmsamoilov 14.5.2016, 19:10
Модератор: Сообщение скрыто.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)