Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / TCP vs UDP в 2017 году

TCP vs UDP в 2017 году

Поделиться

Страницы: 1 2 3 4 Следующая

RammПостоялецwww9 окт. 201710:53#0
Добрый день! Никто не спорит, что при разработке таких штук, как Герои Меча и Магии или крестики-нолики (с сетью) логичнее использовать протокол TCP.
Конечно, есть люди, которые запилят и это на UDP, докрутят свою проверку получения и т.п., но в данном случае это нелогично.
У меня возник вопрос, можно ли использовать TCP для чего-то более тяжелого, например, сетевых стрелялок или гонок?
И вот почему... Весь минус (а я вижу только один) TCP вытекает из его плюсов - он медленнее UDP. Но сегодня скорость интернета у конечного пользователя в 100-300 раз быстрее, чем 10-15 лет назад, сегодня даже не в столицах есть 40-70 мегабит за 300-400 рублей (5-6$).
Предположим, я собираюсь 15 раз в секунду передавать строку в 50-100 байт с информацией об игроке... Неужели при использовании TCP  эти несчастные 200 байт (с учетом служебной информации протокола) будут идти дольше 70 мс. (даже с учетом подтверждения) по каналу в 5 мегабайт/с?
Джек АллигаторПостоялецwww9 окт. 201710:59#1
Ramm, здесь в первую очередь пинг важен.
RadianTORПостоялецwww9 окт. 201711:49#3
ТСР потоковый.
Простой пример:
Представь что ты отправляеш последовательно 15 пакетов о положении 15 игроков. И пакет #3 из-за лага вдруг потерялся.
TCP: получит 2 первых пакета и будет ждать персылки  пакета #3.
UDP: получит все пакеты кроме пакета #3 и будет ждать его пересылки.
RammПостоялецwww9 окт. 201713:01#4
Джек Аллигатор
Вопрос, если пинг с сервером (который я узнаю с помощью команды ping "ip"), например 60 мс., то TCP позволит передать за это время только 1 сообщение максимум? Или гарантированно его передаст?
return [](){};
Во-первых, статье скоро стукнет 10 (!!!) лет. 10 лет назад многое что писали...
Во-вторых, там немного странный подход к передаче данных. Зачем передавать данные каждый кадр? Пользователь нажал кнопку вправо, значит он сместится на один шаг вправо, зачем мне передавать его смещение 100 раз в секунду? Достаточно просто отправить данные, что он начал смещение вправо.
Понятное дело, что будут приходить и отстающие ненужные потоки, но это будет компенсироваться тем, что в этот же кратчайший промежуток времени придут и актуальные данные.
UDP не решает другой проблемы - если я отправлю 3 строки по 100 байт, может так случиться, что вытащить полную информацию корректно не удастся ни из одной.
Вот и получается, что я буду отправлять мусор. Или городить ответы-подтверждения, которые тоже не факт, что дойдут.
Мне надо передать всего по 100 байт каждые 70 мс, передать гарантированно, это всего 1.5 кб\с. Ну хорошо предположим, игроков 32, каждый отправляет 100 байт и получает 3100 байт в ответ, 15 раз в секунду, это 48кб\с, ну +служебная информация + потери... Хорошо, умножим на 3, итого 144кб\с.
И что, TCP по определению не в состоянии отправить 100 байт 15 раз в секунду?
RammПостоялецwww9 окт. 201713:18#5
RadianTOR
> TCP: получит 2 первых пакета и будет ждать персылки пакета #3.
Получит его и все. Т.е. все будет сделано без моего ведома. Я отправляю координаты x,y,z, а так же вектор его движения x1,y1,z1; они доходят, сервер их получает и перенаправляет остальным игрокам. Игрок N:x,y,z,x1,y1,z1.
RadianTOR
> UDP: получит все пакеты кроме пакета #3 и будет ждать его пересылки.
В итоге с сокета я сниму кучку байтов, попытаюсь понять, что за числа, и будет не хватать, например, координаты z. Или при потере не последнего пакета - координаты y. Остается тупо пропускать и ждать, что следующая строка с клиента придет без потерь и я наконец-то смогу ее понять и переслать остальным, в надежде, что она тоже дойдет.

RadianTOR
А, понял, невнимательно прочитал...
Вся прелесть TCP, насколько я понимаю, повторно отправляются только потерявшиеся пакеты. Он не будет каждый раз пересылать цельный массив а потом сверяться с контрольной суммой, и если не совпадет - запрашивать снова.
Другая ситуация, 31 игрок, 3100 байт, я передаю их клиенту, 10% потеряется, что делать в этом случае? Есть риск вообще ничего не понять.

Правка: 9 окт. 2017 13:36

s3dworldПостоялецwww9 окт. 201713:25#6
Ramm
TCP - это поток. Всё приходит ровно так, как ты и отправил. UDP - это пакеты. Тебе никто не мешает засунуть координаты игрока (x, y и z), а так же направление движения в один пакет. Пакеты если и приходят, то всегда целостные (ничего там по байтам не перемещается). А ты видимо хочешь каждую координату в отдельный пакет засунуть, тогда у тебя не только что-то может не прийти, так ещё и не в той последовательности пакеты могут прийти, и я даже слышал что пакеты могут дублироваться.
ТатаринПостоялецwww9 окт. 201713:28#7
websoсket используют только tcp, тоесть все игры под веб кидают по tcp, кроме сделанных на flash там я не в курсе, в своем проекте я раздаю пакеты каждые 100мс в бинарном виде, видел проекты которые кидали json, а некоторые и того хуже, так что не парься и используй TCP, единственное проблема это то что если один пакет задержится то все пакеты замирают пока повторно тот не придет, в тестах ( а я много тестил) это не бывают ни у кого - нужно очень постараться чтобы такая проблема была на современных сетях, может на мобилках если он движется, но там и udp не поможет просто связь оборвется. Зато плюсов в разы больше, и нужны ли тебе те проблемы и самописные велосипеды, подумай иной раз, тут советы много кто давать любит но на практике те еще рукожопы, так что бери на чем проще всего делать.

Правка: 9 окт. 2017 13:32

s3dworldПостоялецwww9 окт. 201713:30#8
Татарин
> webscoket используют только tcp, тоесть все игры под веб кидают по tcp, кроме сделанных на flash там я не в курсе
Во Flash тоже было только TCP (по крайней мере когда я его использовал). В то время UDP можно было использовать только в AIR.
RammПостоялецwww9 окт. 201713:50#9
Татарин
Такие сообщения вдохновляют=)
s3dworld
> Тебе никто не мешает засунуть координаты игрока (x, y и z), а так же
> направление движения в один пакет.
Ого, я просто с TCP работал, и о размерах пакетов не думал, вообще о пакетах не думал - сокеты на TCP все за меня делали... А тут с UDP куча проблем. Как можно установить размер пакета (где об этом почитать, особенно на C# интересно, конкретно - про размер пакетов)
s3dworldПостоялецwww9 окт. 201713:54#10
Ramm
Один send() будет равняться одному пакету.
0iStalkerМодераторwww9 окт. 201714:00#11
В 2017 логичнее использовать  https://ru.wikipedia.org/wiki/SCTP ,... который потоковый и с гарантией доставки, как TCP, но позволяет разбивать данные на сообщения, как UDP. Засада в том, что Microsoft так и не добавила SCTP стек в Windows.
RammПостоялецwww9 окт. 201714:15#12
s3dworld
Быть такого не может... Это с использованием класса Socket? В С#? Получается,  размер пакета 1) не определен, может быть разным 2) не ограничен??? Где можно увидеть подтверждения?

0iStalker
Да, и информации по практическому использованию мало

ZabПостоялецwww9 окт. 201714:18#13
Для части данных не нужна гарантия доставки, для обновления координат объектов, к примеру. Вместо повторной пересылки можно новые координаты послать, они компенсируют пропажу. Но tcp не позволяет реализовать такую линию поведения, он будет пересылать пропавшие данные раз за разом, пока не добьется успеха, за это время накопится еще куча не отосланного, система запросто может начать не справляться с нагрузкой, лаг будет расти и расти, пока не достигнет примерно 30 секунд, после чего соединение рвется.
s3dworldПостоялецwww9 окт. 201714:50#14
Ramm
> Быть такого не может...
Чего быть не может?! Тебе нужно отправить данные? Забиваешь ими какой-то буфер и отправляешь его через send(). Далее произойдёт следующее:
  • Данные придут (внутри них ничего не будет перемешано)
  • Данные не придут
  • Данные придут несколько раз

Правка: 9 окт. 2017 14:50

Страницы: 1 2 3 4 Следующая

/ Форум / Программирование игр / Сеть

2001—2017 © GameDev.ru — Разработка игр