Какой сетевой протокол выбрать для игры?
Собственно, сабж. Необходимо связать два клиента одной игры на разных частях света. какой протокол выбрать? UDP, TCP или что-то другое? В RT-games в основном используется UDP, но мне не нравится, что он по дороге может потерять пакеты или продублировать их.
В 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ы написаны целые главы. Я точно знаю, читал неделю назад. Еще есть подробнейшие примечания про подводные камни и прочие тонкости. Информации очень много. Остальные по вашему откуда информацию берут? Читают книжки.