В рамках изучения клиент-серверного взаимодействия пишу 2D игрушку.
Lang: C++
IDE: VS10
Graphic: OpenGL
Взаимодействие клиента с сервером через сокеты, используя UDP
Клиентская часть только под Win
Сервер пытаюсь сделать кроссплатформенным.
Запнулся на проектировании передачи данных туда-обратно, и еще на нескольких вещах.
А именно:
1) Многопоточность ли?
Посмотрел множествно статей, но так и не понял, всегда ли в клиенте разделяют отрисовку, взаимодейстивие и чтение данных, пришедших на порт, на разные потоки? Или может не потоки, а как-то еще? Подскажите, пожалуйста, как правильно делать.
Если не сложно, cкиньте, пожалуйста, ссылку на удобоваримую информацию о кроссплатформенной реализации многопоточности. Но без Qt.
2) Бесконечный цикл? А может callback'и?
На сколько я понимаю, для постоянного получания данных пришедший на порт в бесконечном цикле гоняется recvfrom. Правильно ли это? Или есть более привлекательное решение этого вопроса?
3) Кроссплатформенность при разработке в Visual Studio 10? Возможно ли?
Серверную часть пытаюсь делать кроссплатформенной. Разделяю код с помощью #if PLATFORM == PLATFORM_WINDOWS. Как потом можно скомпилировать проект под Debian или Ubuntu, или любые другие системы?
3.5) Тонкости кроссплатформенности. Откуда?
Так как я не знаком со всеми тонкостями кроссплатформенной разработки, то могу допускать ошибки и использовать функции, которых может не быть при компиляции под *nix. Как мне отследить различия в аргументах функций или наличия самих функций под разные оси?
1. Отрисовку точно стоит вынести в отдельный от чтения данных поток
2. По поводу бесконечного цикла - именно так. При вызове recvfrom у вас будет блокирован ваш поток пока не придут данные, так что ничего страшного от использования бесконечного цикла у вас не будет. Именно по этому и нужно выносить это все дело в отдельный процесс/поток.
3. Кросплатформенная разработка в вижле? Увы нет, во всяком случае насколько я знаю. Почитайте про cmake и просто make (cmake плохо дружит с вижлой, иногда бывают проблемы и после генерации проекта приходится тратить время еще на настройку, так что чаще проще уж один раз настроить и таскать с собой настройки проекта).
Вообще тут проще побродить по опенсорсным проектам кросплатформенным и посмотреть как там все это дело реализованно.
3.5. ну тут все просто. в linux POSIX, в windows - WinApi (или WinRT если вам хватит поддержки win8+). То есть скажем... код сервера работающий с сокетами у вас под эти две платформы будет различаться на 90% так как все завязано на системное api. То есть вам нужно сделать какую-то прослойку инкапсулирующую сетевую часть, и уже ее реализацию подменять при сборке под конкретную платформу. Либо взять готовое решение для этой прослойки. А вот при реализации бизнес-логики различия между платформами зависят только от самой логики.
>код сервера работающий с сокетами у вас под эти две платформы будет различаться на 90%
Да вроде обычные berkeley-sockets имеют одинаковый апи как для Винды так и для Линукса. Такчто даже работая с голыми сокетами программа будет очень переносимой. Сюда же добавить потоки из стандартной библиотеки, и сервер без больших усилий можно сделать кроссплатформенным.
Насчет того что вы сказали про системы сборок - многие открытые проекты используют сразу несколько систем - для линукса создают make/cmake файлы, а для винды пользуются обыным проектом студии.
в си++.11 появился std::thread который реализует кросс-платформенную многопоточность. Еще можно почитать про boost.thread. Для написания потоков на голом си - существуют posix thread ( для никсов ) и их свободный порт под виндовс платформу.
Кроссплатформенность достигается путем использования кроссплатформенных библиотек. Используйте возможности C++ Standard Library, изучите boost.
В частности, для работы с сетью и распределения задач boost asio.
Нужна или нет многопоточность - вопрос неоднозначный. Если производительности одного потока хватает, то лучше в нее не влезать. А для того, чтобы избежать задержек, использовать асинхронное общение с файловой системой и сетью, концепцию сигналов-слотов (boost asio, boost signals)
Вообще для сети boost.asio, прям совсем однозначно (кроссплатформенно, поддерживает IOCP, epoll, kqueue, неблокируемые сокеты, асинхронность), для многопоточности либо опять же boost, либо C++11, в вашем случае видимо boost (boost.thread, boost.atomic, boost.signals2), так же поглядите на tbb (неблокируемые очереди, алгоритмы и всё такое), легко, понятно, удобно.
Ну и если хотите на linux, то придется поддерживать и несколько компиляторов, а также и несколько стандартных библиотек.
