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

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

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

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

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

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

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


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

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


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

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


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

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

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

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

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

Я такую поделку делал джаст фо фан. Идея была такой:

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

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

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

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

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

Это сообщение отредактировал(а) djamshud - 13.9.2010, 17:40

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

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

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

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

ааа, понял. 


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

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

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

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

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

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

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

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