TCP — система будет за тебя обслуживать передачу чтобы ничего не потерять; UDP — нужно самому так реализовывать передачу данных, чтобы не страдать от (умеренной) потери пакатетов, того что они приходят не в том порядке, и того что ты никогда не узнаешь, приняла ли другая сторона твои данные.
UDP работает быстрее; за счет того, что не ждёт повторной передачи потерянных пакетов.
#2
22:44, 3 апр 2005
MxM
Делай все на TCP когда разберешься , если будет надо то переделаешь на UDP.
- tie_fighter
- Постоялец
#3
23:49, 3 апр 2005
Я начал с UDP, задолбался с проверкой подтверждений, потеряными пакетами и т.п. и в итоге перешел на TCP. По мне так тсп рулит. По крайней мере для локалки однозначно, передачей данных по инету не занимался.
#4
23:59, 3 апр 2005
у TCP заголовок 32 байта, а у UDP — 4. Для инета (и тем более дла модема) это уже критично.
#5
0:08, 4 апр 2005
Для чего-либо быстрее, чем герои — UDP однозначно. Кстати, держать открытыми 2 соединения никто тоже не запрещал.
Есть минутка? — В чём разница между IP, TCP, и UDP?
#6
8:43, 4 апр 2005
MxM
Как правило они используються вместе, критическая информация по TCP, не критическая по UDP.
#7
9:32, 4 апр 2005
Altair
Приведи пожалуйста тот док в котором написнно что заголовок UDP = 4 байта? Насколько я знаю он равен 16 байтам 🙂
#8
10:02, 4 апр 2005
Большое спасибо, я уже начинаю потихоньку разбираться в этом. Вы реально мне помогли. Значит, если на первом месте стоит скорость доставки потока, то лучше использовать технологию UDP, а если качество, то TCP. А как насчет DirectPlay?
#9
10:58, 4 апр 2005
всё зависит от специфики игры на самом дклк.
к примеру игры типа Q2 сделанны на протоколе UDP. Там при, огромном потоке информации (персонаж всегда двигается и он не один) не критична потеря даже 5 пакетов подряд. Так называемые ЛАГИ — это же совершенно безумные потери, от 20 пакетов :)..
А если игра на пдобии MMORPG, то там потеря даже одного пакета критична. Взять к пример Анархию Онлаин (каюсь, играл, грешен :)), там критична ВСЯ информация, например партия из6 игроков пошла мочить кого-то, чувствует не справляется и фиксер решил всех подальше унести от греха и прочей фигни.
Пакет с умением пролетает мима серваков прямо в /dev/null, и вс бы ничего, тока востаналивается сия фигня 90 сек. За котрых планомерно выносят всю пати. После чего фиксера опукает пати, он объясняет ситуацию, (пару скриншотов сделал), и вся пати начинает опускать фанком. Они рассказывают своим знакомым. Будут ли люди играть в игру, где постоянно пропадает, то что-ты хочешь сделать?
Унифицированного протокола нет.
#10
11:07, 4 апр 2005
MxM
А если качество и доставка — то UDP 🙂
Никто же не мешает тебе самому запрограммировать механизмы гарантированной доставки. Я, например, пошёл по этому пути и не жалуюсь.
Смотри, в чём фича:
TCP и UDP | Что это такое и в чем разница?
К примеру ты отправляешь клиенту координаты игроков и прочую быструю фигню по UDP. По TCP же отправляешь команды, которые должны выполнится в обязательном порядке.
Теперь. Например ты отправляешь клиенту команду, что в точке x,y,z должен быть баальшой бубух с кучей частиц. Он упаковывается в TCP, отправляется и 1 пакет в потоке теряется. Клиентский TCP отправляет обратный пакет серверу с указанием пакетов, которые не принялись в текущем фрейме (не уверен, что оно так называется). Серверский TCP отправляет назад нужные пакеты.
Итд.
Всё это время (3*(ping/2)) у клиента взрыва нет. К тому же все команды после этого взрыва тоже стоят в очереди.
По UDP же есть методы гарантированной доставки, которые в таких ситуация срабатывают за время, близкое к ping/2.
То есть — UDP более гибкий протокол, который можно и нужно настроить под свои нужды.
А TCP остаётся только для HMM.
#11
11:36, 4 апр 2005
Для шутеров с физикой — UDP, для всех остальных игр прекрасно хватает TCP. В gd-algorithms недавно было обсуждение на эту тему. Все игрушки от Blizzard работают через TCP
#12
12:28, 4 апр 2005
Совсем запутался )))). Большое спасибо за помощь. А как насчет DirectPlay?
#13
13:27, 4 апр 2005
MxM
Слушай меня .
Я не советую как сделать так чтобы это работало максимально хорошо! Я говорю то что лучше именно для тебя !!
Для новичка , лучше всего TCP. потом уже когда наберешь опыт и поймешь что тебе нужен UDP , тогда и вопросы будут другие. Но если спрашиваешь с чего начинать , однозначно делай TCP.
#14
17:06, 4 апр 2005
Кстати — реализовать TCP-подобный алгоритм самому и пихать его как часть UDP-пакетов тоже никто не запрещал.
Так что моё мнение — UDP. Трус не играет в хоккей 🙂
Источник: gamedev.ru
Должен ли я использовать UDP или TCP для моей игры в стиле Minecraft?
Кроме того, является ли хорошей практикой отправлять на сервер сообщения об уничтожении и размещении блоков? Я предполагаю, что при запуске клиента ему сначала нужно загрузить карту. И тогда изменения в карту будут вноситься параллельно картам на клиентах и той, что на сервере.
Наконец, должен ли я передавать позиции символов только тогда, когда они меняются (имеет тенденцию к TCP), или я должен постоянно отправлять их (имеет тенденцию к UDP)?
задан 24 июн ’13, 20:06
TCP медленнее, UDP быстрее. Также гарантируется TCP, а UDP — нет. Поэтому, исходя из ваших приоритетов, вы должны взвесить различия. — apollosoftware.org
Имейте в виду, что помимо обсуждаемой проблемы надежности, UDP также создает проблемы с обходом NAT. Вам нужно будет использовать такие методы, как штамповка UDP и т. Д. — dhruv chopra
2 ответы
Я чувствую, что в приведенной ниже ветке есть полезная информация, которая будет вам полезна. Как сказал AmitApollo, в двух словах UDP быстрее, но менее надежен. Если вся ваша информация, которую вы отправляете по этой сети, абсолютно необходима, тогда TCP может быть лучшей реализацией. Вы всегда можете попробовать оба варианта и посмотреть, какая у вас производительность/задержка. В общем, большинство игр с быстрым темпом / в реальном времени, о которых я читал, использовали UDP.
ответ дан 23 мая ’17, 11:05
Ветка оказалась полезной. Дело в том, должен ли я постоянно отправлять позиции ai-символов или только при изменении позиции? — советскийчувак
Ну, если там позиция не изменилась, зачем вам отправлять туда позиции? Просто попросите клиента «приостановить» обнаружение коллизий, пока вы не получите другой пакет в новой позиции. — Сирал
У вас есть хорошая мысль 🙂 Но должно ли обнаружение коллизий выполняться на стороне сервера или на стороне клиента? Потому что, если вы делаете это только на стороне сервера, отправки позиций будет достаточно. Если я выберу этот подход, я мог бы также сделать ИИ на сервере. Это хорошая идея? — советскийчувак
Что ж, было бы неплохо синхронизировать игроков, делая это на стороне сервера, и предотвращать взлом. Меня всегда интересовал один и тот же вопрос. — Сирал
Приятно просто позволить клиенту быть терминалом дампа. Поскольку не потребуется так много обновлений, я думаю, что я выберу подход tcp. Если это станет слишком медленным, я попробую lidgren с надежностью. А поскольку клиент представляет собой терминал дампа, нам не нужны какие-либо переговоры между сервером и клиентом, чтобы увидеть, какой из двух содержит правильные игровые данные. Спасибо за помощь кстати 🙂 — советскийчувак
Все должно быть проверено сервером, чтобы игру нельзя было взломать или изменить; либо путем изменения адресов памяти, либо какой-либо другой уязвимости.
И ИИ/нахождение пути, и коллизия должны проверяться сервером, однако использование TCP для обоих вызовет перегрузку из-за рукопожатия и накладных расходов окна. Сегодня MMO используют пакеты UDP с пользовательским контролем перегрузки и рукопожатиями. В качестве первой версии вы должны просто использовать UDP-пакет — когда пакеты теряются или теряются при передаче, игра просто останавливается. lag и зависать до тех пор, пока не пройдет UDP-пакет. Последующие версии вашей игры могут реализовать пользовательскую настройку подтверждения с помощью UDP, чтобы персонаж приостанавливался до проверки.
Client — Movement request UDP —> Server Client: Character is frozen Server: Validate coordinates on map Client:
Это гарантирует, что каждое движение персонажей будет действительным. Вам также понадобятся ключи безопасности или защита протокола, чтобы не каждый мог отправить координаты для проверки.
Вы можете подумать, что этот дизайн будет отставать от вашей игры, но при правильном дизайне он будет безопасным и свободным от взлома на стороне клиента. Не забудьте спроектировать свои UDP-пакеты как можно меньше (по размеру).
Источник: stackovergo.com
Должен ли я использовать UDP или TCP для моей игры в стиле майнкрафт?
Я создаю двухмерную игру в стиле майнкрафт, где карта хранится в двумерном массиве int. Вы можете размещать и уничтожать блоки, а персонажи с искусственным интеллектом будут ходить по карте. Игра сделана с использованием xna / c #. Проблема в том, что у меня нет большого опыта кодирования сетевых игр.
Какой протокол мне следует использовать? UDP, TCP? Или, может быть, библиотека lidgren? (который использует надежность UDP +)
Должен ли я выполнять следующие действия на клиенте, сервере или на обоих?
- AI / поиск пути
- обнаружение столкновений
Кроме того, является ли хорошей практикой отправка на сервер сообщений об уничтожении и блокировке места? Я предполагаю, что когда клиент запускается, ему сначала нужно загрузить карту. И тогда изменения в карту будут внесены параллельно с картами на клиентах и на сервере .
Наконец, должен ли я транслировать позиции символов только тогда, когда они меняются (склоняется к TCP), или я должен постоянно отправлять их (имеет тенденцию к UDP)?
Любая помощь полезна 🙂
PS: извините за плохое качество моего английского (я голландский)
sovjetdude 24 Июн 2013 в 23:18
2 ответа
Лучший ответ
Мне кажется, что в приведенной ниже ветке есть полезная информация, которая будет вам полезна. Как сказал AmitApollo, вкратце UDP быстрее, но менее надежен. Если вся ваша информация, которую вы отправляете по этой сети, абсолютно жизненно важна, тогда TCP может быть лучшей реализацией. Вы всегда можете попробовать оба варианта и посмотреть, какие у вас показатели производительности / задержки. В общем, в большинстве динамичных игр в реальном времени, о которых я читал, использовался протокол UDP.
Community 23 Май 2017 в 13:29
Все должно быть проверено сервером, чтобы игру нельзя было взломать или изменить; либо изменением адресов памяти, либо какой-либо другой уязвимостью.
И AI / поиск пути, и коллизия должны проверяться сервером, однако использование TCP для обоих вызовет перегрузку из-за рукопожатия и накладных расходов окна. Сегодняшние MMO используют UDP-пакеты с настраиваемым контролем перегрузки и рукопожатиями. В качестве первой версии вы должны просто использовать UDP-пакет — когда пакеты теряются или теряются при передаче, игра просто lag зависает до тех пор, пока UDP-пакет не пройдет. Последующие версии вашей игры могут реализовать настраиваемую настройку подтверждения с помощью UDP, чтобы персонаж останавливался до тех пор, пока не будет подтвержден.
Client — Movement request UDP —> Server Client: Character is frozen Server: Validate coordinates on map Client:
Это гарантирует, что каждое движение персонажей допустимо. Вам также понадобятся ключи безопасности или безопасность протокола, чтобы не каждый мог отправить координаты для проверки.
Вы можете подумать, что этот дизайн будет отставать от вашей игры, но при правильном дизайне он будет безопасным и свободным от взлома на стороне клиента. Не забудьте, что ваши UDP-пакеты должны быть как можно меньше (по размеру).
Источник: question-it.com