Достаточен ли протокол TCP для многопользовательских игр в режиме реального времени?

В тот же день TCP-соединения по dialup /ISDN /медленному широкополосному соединению приводили к прерывистым, отстающим играм, потому что один упавший пакет привел к повторной синхронизации. Это означало, что многие разработчики игр должны были реализовать свой собственный уровень надежности поверх UDP, или они использовали UDP для сообщений, которые могли быть удалены или получены не в порядке, и использовали параллельное TCP-соединение для информации, которая должна быть надежной.

Учитывая, что средний пользователь имеет более быстрые сетевые подключения, может ли игра в реальном времени, такая как FPS, обеспечивать хорошую производительность по TCP-соединению?

56 голосов | спросил kevin42 15 J000000Thursday10 2010, 17:19:12

9 ответов


36

Я бы сказал, нет. Промежуточная информация об игровых объектах должна быть как можно быстрее, и для этого лучше использовать UDP, потому что надежность не является 100% crutial. Даже в современных соединениях UDP все еще достаточно медленный, и вам нужно сделать некоторые специальные соображения для интерполяции и т. Д. Даже с точки зрения количества переданных данных, TCP добавит к этому значительные накладные расходы.

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

ответил Sean Edwards 15 J000000Thursday10 2010, 17:33:02
11

Поскольку Flash не поддерживает UDP, просмотрев многопользовательские флеш-игры, вы можете получить довольно хорошее представление о том, что возможно с TCP /IP, а что нет. В принципе, вы можете создавать игры в режиме реального времени, если они не полагаются на молниеносное время отклика. Несколько примеров:

http://www.xgenstudios.com/play/stickarena

http://everybodyed.com/

Если у вас есть возможность использовать UDP, вам действительно нужно, но с Flash вы, к сожалению, не получите эту опцию.

ответил Iain 15 J000000Thursday10 2010, 17:48:26
8

Это зависит.

Игры, такие как World of Warcraft, используют TCP для их общения, потому что вы обошли многие проблемы, используя его. В результате может быть более высокий пинг, но для многих игр это приемлемо. Вы должны делать пространственную интерполяцию, даже если вы используете UDP в качестве своего протокола.

ответил Christopher 15 J000000Thursday10 2010, 20:20:20
6

Если ваша архитектура клиент /сервер чиста, транспортный уровень (почти) не имеет значения.

TCP имеет некоторые недостатки, но они легко защищены.

Итак, да, TCP и мозг - это все, что вам нужно.

С обычными сетевыми настройками (прокси, брандмауэрами и т. д.) сегодня UDP практически бесполезен для всех, кроме локальных (чтение: LAN) игр.

ответил Andreas 16 J000000Friday10 2010, 18:01:40
5

Его вполне приемлемо использовать TCP вместо UDP - если вы отключите алгоритм Нагла .

Как только вы отключите Nagle, у вас будет большая скорость UDP и будет полностью в состоянии сделать игру с дрожью . Действительно, я сделал такую ​​игру, используя TCP во Flash:

http://2dspacemmo.wildbunny.co.uk

Надеюсь, что это поможет!

ответил wildbunny 12 12012vEurope/Moscow11bEurope/MoscowMon, 12 Nov 2012 17:31:19 +0400 2012, 17:31:19
4

Для игр FPS мы всегда используем UDP. Особенно, если вы делаете шутер с дрожанием, где пинг имеет значение.

ответил Corv1nus 15 J000000Thursday10 2010, 20:30:33
4

Это зависит от вида игры.

Некоторые игры, такие как RTS, намного лучше работают по TCP и обычно используют TCP все время.

Реальная проблема с TCP заключается в том, что если вы получаете потерю пакетов - даже небольшую сумму - тогда соединение «останавливается» до тех пор, пока не произойдет повторная передача. ОС не может доставлять данные нестандартного порядка в приложение (это нарушает гарантии TCP, но также TCP не показывает границы рамки приложения). Срыв соединения означает, что позднее поступают поздние данные. Но в игре (например, FPS) устаревшие данные бесполезны.

С UDP приложение получает возможность выбирать, что он делает с поздними или нестандартными данными. Он может (и для такой игры, как FPS, как правило, делает) игнорировать старые данные и просто принимать последние. Случайный потерянный пакет не задерживает последующие пакеты вообще. Если в итоге приходит пакет с задержкой, его можно игнорировать.

ответил MarkR 13 22012vEurope/Moscow11bEurope/MoscowTue, 13 Nov 2012 01:19:51 +0400 2012, 01:19:51
3

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

Ни один из других ответов здесь не указывает на очевидный способ доказать это.

Возьмите несколько простых фактов

  • IP-заголовок составляет 20 байтов независимо от того, какой протокол вы используете.
  • Заголовки UDP имеют 4 байта
  • Заголовки TCP - 20 байт.

Поэтому каждый раз, когда вы отправляете сообщение по 1 байт по линии, вы фактически отправили либо 25, либо 41 байт в зависимости от протокола, предполагая, что IP-заголовок также необходим.

Источники

:

Мой совет

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

Пример

Предположим, что я отправляю 10 сообщений по 1 байт за каждое обновление в моей игре, и я обновляю около 60 кадров в секунду, поэтому мне нужно отправить 60 * 10 = 600 байт в секунду фактических данных сообщений + соответствующие заголовки.

Теперь, в зависимости от игры, я мог бы отправить это все как одно сообщение, поэтому мои накладные расходы с уровня TCP составляют всего 40 байт (фактически стоимость UDP составляет 20 байт в секунду), не имея накладных расходов потенциальной стоимости 600 байтов (потому что мне может потребоваться отправить весь поток сообщений).

Если, однако, жизненно важно, чтобы каждое сообщение отправлялось само по себе в тот момент, когда оно было готово к отправке, у меня есть 600 сообщений (также 600 байт) + 40 * 600 = 24 тыс. накладных расходов TCP или ~ 14k служебных данных UDP в секунду + 600 байтов данных сообщения.

Опять же, мы задаем вопросы, насколько важны эти сообщения, насколько они часты, и можно ли их каким-то образом скомпоновать, чтобы уменьшить накладные расходы?

Это основано на связке однобайтовых сообщений, как правило, вы делаете что-то совсем другое, но не зная, что необработанные данные отправляются с трудом, чтобы доказать это, если TCP лучше подходит для вашей ситуации, чем UDP.

Итак, будет ли это работать?

Ну, если у вас типичный fps, и положение важно (чтобы избежать обмана или неправильных решений), вам нужно знать, что ваш сетевой поток является реальным, но 32 игрока каждый потоковой передачи, что 24k + сообщения байтов назад и вперед ( так что 768 КБ /с + сообщения) ... это около 10 Мбит /с широкополосной линии только для отдельных заголовков на основе отправки по меньшей мере 1 сообщение за кадр от каждого клиента ко всем другим клиентам через сервер.

Вы, очевидно, не будете кодировать ваш сервер и клиент для работы таким образом, и размер сообщений, скорее всего, будет намного больше и, вероятно, будет немного менее частым, чем 1 байт на фрейм в большинстве ситуаций, поэтому трудно сказать, не видя реальный мир «это данные, которые мне нужно отправить».

Мой случай

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

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

для других: TCP просто не будет делать, и они могут использовать только UDP, но должны признать, что он не даст им гарантий относительно того, что они получают (заказ /гарантия прибытия).

Другие соображения

Многие плохо закодированные игровые движки обрабатывают все в основном потоке процессора, поэтому для процессора часто требуется очень мало времени для обработки сетевого кода, достойная реализация как сервиса, так и клиента будет полностью асинхронной и возможно нажимать и тянуть сообщения в партиях.

Есть несколько хороших сетевых библиотек, но, как видно здесь, многие, похоже, придерживаются мнения, что UDP «просто лучше», сначала учитывает ваши собственные потребности, и это может быть не так, и найти библиотеку, которая не влияет на то, что вы делаете, может привести к плохо кодированной настройке TCP по сравнению с вариантом UDP в той же самой lib (я просто говорю, что видел это, и тесты нагрузки доказали это).

Создайте что-то сначала техническую базу данных, которую вы хотите отправить, и протестируйте ее, затем выполните математику, чтобы ее масштабировать, в худшем случае загрузите ее, развернув ее в облаке и попросите 50 компьютеров запустить тестовый клиент, чтобы узнать, он может обрабатывать ваш лимит в 32 игрока за игру (или любые ограничения, которые могут быть у вас).

ответил War 9 Mayam16 2016, 03:17:45
2

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

ответил Shashwat 17 J000000Tuesday12 2012, 08:32:37

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132