| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > С/С++: Кроссплатформенное программирование, Qt/Gtk+/wxWidgets > [Qt] Дипломная работа : Сетевая нарды |
| Автор: IKM2007 13.9.2010, 14:45 |
| Доброго дня и всех с праздником. Тема дипломной "Сетевая нарды". В прошлом году сделал курсовую по этой же теме, но реализовал ее только для локальной сети, то есть архитектура программы была такой, что о работе в интернете не было и речи(не было отдельного сервера, все сообщения передавались от компа к компу). Теперь надо все сделать как надо + реализовать игру с компом. Думаю сделать так : сам проект будет состоять из двух отдельных модулей: client.exe и server.exe. Весь анализ входящих/исходящих сообщении + игра с компом будет на плечах клиентской части, серверная часть будет только для того, чтобы получать сообщения и отправлять их адресату. То есть в нем будет список всех играющих пар с их данными и когда сервер получает какое-то сообщение, он смотрит от кого это сообщение, находит его в списке и отправляет то же сообщение оппоненту игрока. В серверной части также будет список тех игроков, которые ждут игры. Когда кто-то входит в сетевую игру, он может подключится к любому ждущему игроку, а также может "создать игру" и сам ждать кого-то. В общих чертах описал то, что хочу сделать. Если есть какие-то замечания, буду рад слушать. И еще подскажите инфу, где я могу прочитать о многопоточных серверах и способах их реализации на Qt. + не помешало бы любой другой информации по теме. |
| Автор: IKM2007 13.9.2010, 15:58 | ||||
Да, но подумал не нагружать сервер, он и так будет многопоточным, не будут ли задержки, если допустим одновременно будут играть 100 пар? Он будет анализировать 100 поступающих сообщении одновременно.
Не понял о чем вы. Можно поподробнее? |
| Автор: Любитель 13.9.2010, 16:25 | ||
Любые "серьёзные" сервера хранят всё у себя. Проблем не будет. Другое дело - насчёт многопоточности. Если у тебя будет по потоку на клиента, то это будет (с точки зрения производительности) очень плохо. Надо органиозвывать асинхронную обработку (неблокирующая работа с сокетами и вообще вводом/выводом). Ну, я имел ввиду, что у тебя будет одна библиотека, где будут классы поля, игроков и т. д. С ней будет работать клиент (в случае game with computer) и сервер (в случае обычного мультиплеера). |
| Автор: IKM2007 13.9.2010, 16:45 | ||||
Что порекомендуете почитать по теме?
Вы про dll? Не знал, что их можно использовать для хранения временных данных. Что порекомендуете почитать о создании dll? Если я вас правильно понял, то общая структура программы будет следующей: server.exe - Принимает сообщение, анализирует у себя игру и отправляет обеим клиентам все координаты шашек, также при получении сообщения о броске костей у себя генерирует случайные числа и отправляет их обеим клиентам. То же самое касается остальной служебной переписки между клиентами(там кто-то вышел из сети, удвоил счет, сдался и т.д.). Здесь я не понял как будет происходить режим чтения? Думаю сделать два потока, один все время ждет сообщении и читает их, а другой поток асинхронно все анализирует и отправляет сообщения адресатам. Но я все это очень мутно представляю, так как никогда ничего такого не реализовал, да и с теорией не очень знаком. Поэтому буду благодарен за инфу. server.dll - Хранятся данные для игры через сеть. client.exe - Принимает сообщение о расположении всех шашек на экране, рисует их, отправляет сообщение о изменении местоположения шашек на экране + контролирует все передвижения шашек, то есть запрещает недопустимые ходы. Когда нажимают на кнопку бросание костей, отправляет серверу соответствующее сообщение и оба клиента принимают данные о выпавших костях. Так же и осуществляется другая служебная переписка между клиентами. client.dll - Хранятся данные для игры с компьютером. |
| Автор: djamshud 13.9.2010, 17:37 |
| Я такую поделку делал джаст фо фан. Идея была такой: * сервер-партия обслуживает одну партию из двух участников; реализация правил игры - кидает кубики и т.д.; * сервер-организатор хранит историю и юзерей, соединяет их т.д.; * клиент-ИИ может быть выбран себе в соперники; * клиент-морда позволяет выбирать себе соперников, двигать шашечки и ехать:). Сделал большую часть, но потом надоело. Может быть когда-нибудь и доведу до ума. * сервер-партия полностью готов; * сервер-оргииназтор в зачатке; * ИИ нет; * морда на куте позволяет двигать шашечки по правилам; * морда и клиент-партия используют общую библиотеку с реализацией большей части правил игры и сетевого протокола. Исходники полурабочего поделия открывать не хочу, но могу помочь в конкретных вопросах. Добавлено @ 17:39 И да. На сервере многопоточность излишняя. |
| Автор: Любитель 13.9.2010, 18:09 | ||
Всмысле? Данные в памяти. Я имел ввиду библиотеку, где будут классы, инкапсулирующие это (хранение данных о состоянии игры и управление им). Т. е. грубо говоря - некая библиотека core. И отдельно два приложения: server, client (ещё в идеале предусмотреть у сервера некий протокол для просмотра текущего состояния, бана игроков и т. д. - зависит от фантазии и доступном времени). В плане сетевой архитектуры, основных проблем две: 1. Пул потоков (так как создание/уничтожение потока - операция не быстрая, делать это на каждом запросе накладно). 2. Non-blocking input/output. И то, и другое в современном Qt есть из коробки - т. е. особых проблем не должно быть. Делать распаралеливание внутри кода обработки одного сообщения от клиента - не стоит (выиграть этим ничего не выиграешь всё равно). |
| Автор: IKM2007 13.9.2010, 18:39 | ||
ааа, понял. Почему? По моему должны быть как минимум два потока, один всегда ждет, второй работает. |
| Автор: Любитель 13.9.2010, 20:02 | ||
Ну, если клиентов может быть относительно много, то нужен пул потоков (потоков 30-50, я думаю) - это 100%. |
| Автор: IKM2007 13.9.2010, 20:32 | ||
Нет ну в реальности клиентов может быть от силы 2, так как прога будет тестироваться на локальке в кругу преподавателей, но во время защиты один из них может сказать, что проект не будет нормально работать, если игроков будет много, поэтому и хочу все сделать так, чтобы не нашли к чему придираться. Ладно, сейчас все обсуждать думаю не имеет смысла, так как очень поверхностно все представляю. Думаю изучить инфу по теме, затем если будут вопросы, напишу в этой теме. Спасибо за быстрые ответы. + |
| Автор: djamshud 13.9.2010, 20:40 |
| IKM2007, на двух можно конечно и потоки использовать, но вообще более правильный вариант организации работы с клиентами уже был озвучен. Учитесь уж сразу делать хорошо, благо пока студент - бесплатно:). |
| Автор: asd 14.9.2010, 08:27 |
| Имхо, идея с реализацией на стороне клиента, не так уж плоха. Нарды - игра с полной информацией, поэтому читерить в ней не получится(кубики естественно бросает сервер) А статистику на сервере в любом случае можно вести, ходы то через него проходят. С рассинхронизацией тоже можно что-нибудь придумать(можно при каждом ходе даже посылать - для нард трафик быдет очень маленьким). Зато получим абсолютно не требовательный к ресурсам сервер. |
| Автор: boostcoder 17.9.2010, 16:43 | ||
что-то многовато. в моей реализации игрушки, всего 5 потоков. один поток обрабатывает цикл с boost::asio::ip::tcp::acceptor, проверяет IP на предмет бана, и отправляет его в пул и 4ех потоков(кол-во ядер) на основе boost::asio::io_service. пока видел максимум из 3729 клиентов одновременно. загрузка ядер по 17 процентов. но на qt я бы не стал такое писать. |
| Автор: dmsamoilov 14.5.2016, 19:10 |
Модератор: Сообщение скрыто. |