Какой сетевой протокол выбрать для игры?

В quake можно было выбирать. Так что реализуй оба. Я настаиваю.

В принципе мысль. В чем еще различие, кроме дублирования\потери?

Интересно, как Вы пишете игры, если спрашиваете такие ответы? Можно не отвечать.

А Вы не знаете, что люди еще могут учиться в процессе разработки?

Игроки взаимодействуют между собой напрямую или через сервер?
ЕМНИП, UDP не пройдут через роутер внутрь интрасети.

какого рода игра? какой объем трафика будет передаваться?

Это называется опыт. В любом случае должна быть база.

Я никогда не писал общение с сетью. В основном я изучал API и внутреннее устройство ОСей.

Пока планируется напрямую, но, думаю, что впоследствии (возможно) будет сервер.

Двухмерная бродилка по типу напоминающая Terraria, только с бОльшей геологической составляющей. Взаимодейтвие с почвой, предметами, мутирование жизненных форм.

Передача данных, думаю будет примерно такой ширины:

Просто передача данных управления (около 10 кнопок) + данные о взаимодействии (где-то 100 байт) + Данные об изменении окружения (тоже оокло 100 байт).

Чтоб основы понять тебе максимум 3 дня потребуется. Что по сетевому программированию смотреть на ЛОРе 1000 раз обсуждалось. Вопросы отпадут сами. Удачи.

Если вы не заметили, я не спрашивал, что почитать по сетевому программированию. Я спрашивал, какой конкретно протокол лучше для поставленной задачи. Что почитать по протоколу я сам найду. Меня интересует личный опыт других и трудности, с которыми возможно я столкнусь. Так, например, ответ trex6 был в тему:

ЕМНИП, UDP не пройдут через роутер внутрь интрасети.

В справочнике такого не найдешь.

А вы, товаrищь, просто тролль.

Начать можно с TCP, потом поймёшь что не так с таким подходом, прочувствуешь на «шкуре». Или может даже всё будет нормально.

А поднять с нуля свой протокол через UDP сразу не получится, нужно хорошо понимать как обрабатывать потери пакетов в приложении и т.п. Без твёрдого понимания необходимости UDP лучше по этому пути не ходить.

В справочнике такого не найдешь.

да это чушь, существует 100500 методов преодоления такой неприятности

TCP: потом поймёшь что не так с таким подходом

UDP: лучше по этому пути не ходить.

Вы «опустили» оба протокола. Так что же выбрать?

да это чушь, существует 100500 методов преодоления такой неприятности

Я имел в виду наличие в справочнике не метода «обхода», а наличие самой проблемы.

Вы «опустили» оба протокола. Так что же выбрать?

почему это опустил? Ясно же написал - начать лучше с TCP. Т.к. он из коробки решает множество проблем о которых ты ещё не догадываешься, я так думаю.

От UDP в твоей задаче тоже можно получить профит и потенциально сделать лучше чем через TCP. Но для этого нужно знать многие нюансы и проблемы передачи данных через датаграмы.

Просто наблюдение из жизни. Можно найти достаточно много продуктов с реализациями протокола приложения через TCP и UDP. И мало кому удавалось с помощью UDP существенно лучше решать задачи несмотря на значительно бОльшие затраты ресурсов на разработку варианта протокола поверх UDP.

Я имел в виду наличие в справочнике не метода «обхода», а наличие самой проблемы.

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

От UDP в твоей задаче тоже можно получить профит и потенциально сделать лучше чем через TCP. Но для этого нужно знать многие нюансы и проблемы передачи данных через датаграмы.

Я так понимаю, что надо (я это все в свой фреймворк засуну, на котором и игра висит и все остальное) : 1) Сделать сетевые соединения и передачу данных через TCP. 2) Заставить пункт 1 работать. 3) Посмотреть на результат. Если работает криво и\или медленно, идем дальше 4) Разработать алгоритм получения данных с допущением дублирования\потери пакетов. 5) На его основе сделать UDP-обертку.

Так?

да

Почти.

Только между пунктом 3 и 4 нужно добавить пункт 3а: разобрать проблему по кусочкам, понять почему не достигается нужный результат.

Некоторые проблемы можно решить тюнингом TCP сокетов. Например, опциями TCP_CORK/TCP_NODELAY. И когда уже будет ясное понимание, что в рамках TCP проблема неустранима, то переходить к пункту 4. В процессе разборов полёта появится понимание как можно сделать лучше поверх UDP.

Да всё там есть. Про маршрутизацию и всякие там NATы написаны целые главы. Я точно знаю, читал неделю назад. Еще есть подробнейшие примечания про подводные камни и прочие тонкости. Информации очень много. Остальные по вашему откуда информацию берут? Читают книжки.

Хорошо, всем спасибо!

Хз возможен ли хотя бы теоретически NAT для UDP, так, что для игры - TCP, а UDP - только в локалке для получения списка игр (TCP для этого не катит).

SCTP.

Яростно плюсую.

>ЕМНИП, UDP не пройдут через роутер внутрь интрасети.

udp-пакеты прекрасно DNAT-ятся iptables'ом. Другое дело, что, как правильно заметил ТС(на правах К.О.) от потерь UDP не защищает и нужно
это учитывать/бороться с этим...

>возможен ли хотя бы теоретически NAT для UDP

в iptables - хоть для icmp, хотя для udp. Причем именно DNAT, про SNAT и так понятно

Плюсую, но в винде ЕМНИП он все еще не поддерживается.

кстати для p2p-решений и multihome-сетей протокол довольно вкусный, жаль что малораспространенный

>прекрасно DNAT-ятся iptables'ом
Стандартный роутер из магазина это умеет? Просто мне казалось, что нет.

умеет

К пример - D-Link DSL-2540U умеет. И, учитывая, что это не самый лучший роутер, я думаю много еще кто умеет...

s/К пример/К примеру/ конечно же...

А если к нему несколько машин подкючены, то как он это делает? Я имею ввиду входящие UDP пакеты. Где об этом можно почитать?

Поддержи вымирающее, сделай на IPX ;-)

также как и TCP, смотри как делается DNAT в iptables. Благодаря механизму conntrack UDP пакеты обладают некоторыми свойствами TCP-пакетов(в частности состояниями RELATED,ESTABLISHED и, в новых версиях NetFilter, состоянием DNAT, которое доступно по критерию -m conntrack, вместо устаревшего критерия -m state)

Сначала определитесь с логикой взаимодействия, с кол-вом игроков и т.д.

http://enet.bespin.org/ http://opensource.linuxgamepublishing.com/grapple/