Чи достатньо протокол TCP хороший для багатокористувацьких ігор у режимі реального часу?


57

Знову ж таки, TCP-з'єднання через комутований / ISDN / повільний широкосмуговий зв'язок призвели до похмурих, млявих ігор, оскільки один скинутий пакет призвів до повторної синхронізації. Це означало, що багатьом розробникам ігор довелося реалізувати свій власний рівень надійності поверх UDP, або вони використовували UDP для повідомлень, які можуть бути відхилені або отримані з ладу, і використовували паралельне з'єднання TCP для інформації, яка повинна бути достовірною.

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


Відповіді:


36

Я б сказав, що ні. Просторова інформація про ігрові об’єкти повинна бути якомога швидшою, і для цього краще використовувати UDP, оскільки надійність не є на 100% важливою. Навіть у сучасних підключеннях, UDP все ще досить повільний, що вам доведеться зробити деякі особливі міркування щодо інтерполяції та іншого. Навіть лише з точки зору кількості переданих даних TCP додасть цьому значні витрати.

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


7
Шон майже на гроші. Якщо випадково ви розробляєте гру в C # /. NET (ви знаєте, що хочете!), Я визнав мережеву бібліотеку Lidgren ( code.google.com/p/lidgren-library-network ) неабиякою гарний вибір. Він навіть забезпечує упорядкований, надійний обмін повідомленнями через UDP, якщо вам це потрібно.
Майк Стробель

2
Нерозумно змішувати і TCP, і UDP; в результаті того, як TCP виконує контроль потоку, він може викликати втрати пакетів. (джерело: isoc.org/INET97/proceedings/F3/F3_1.HTM )
Джейсон Козак

4
Також важливо пам’ятати, що в деяких випадках кінцеві користувачі будуть сидіти за Інтернет-провайдерами, які блокують UDP-трафік, матимуть налаштування маршрутизатора, які запобігають трафіку UDP, або в іншому випадку знаходяться в ситуації, коли використання UDP менше, ніж ідеально. У тих випадках, якщо ваша гра може її підтримати, можливість повернутися до спілкування TCP - це дуже зручно.
Чарльз Елліс

Ще один момент для UD полягає в тому, що його, природно, орієнтований на пакет, ви повинні емулювати це в TCP, якщо це потрібно (boilderplatecode), на жаль, більш сучасні протоколи не підтримуються Windows (це смокче)
Quonux

11

Оскільки Flash не підтримує UDP, дивлячись на багатокористувацькі Flash ігри, ви можете отримати гарне уявлення про те, що можливо з TCP / IP, а що ні. В основному ви можете створювати ігри в режимі реального часу, доки вони не покладаються на блискавичний час реагування. Кілька прикладів:

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

http://everybodyedits.com/

Якщо у вас є можливість використання UDP, ви дійсно повинні, але при Flash ви, на жаль, не отримуєте цього варіанту.


8

Це залежить.

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


1
Це не просто пінг. Є причина, чому в WoW немає зіткнень між гравцями та гравцями. Було б занадто важко зробити добре. WoW може використовувати TCP, оскільки те, де ти стоїш, не має великого значення. Націлювання та атака не залежить від реальної позиції монстра або гравця противника. Якщо ви дбаєте про ці речі, то TCP зашкодить ігровому досвіду.
Nuoji

6

Якщо архітектура вашого клієнта / сервера чиста, транспортний шар (майже) не має значення.

TCP має деякі недоліки, але вони легко обходять.

Так що так, TCP і мозок - все, що вам потрібно.

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


7
Якщо ви заявляєте, будь ласка, залиште коментар, чому. Ми використовуємо TCP і ніколи не мали жодної проблеми з ним.
Андреас

3
Я не бачу доречності загальних налаштувань мережі в цьому. Брандмауери взагалі заважають лише хостинг-серверам, але навіть тоді, незалежно від протоколу, тоді як проксі-сервери фактично збільшують ризик затримки або скидання пакетів, роблячи UDP набагато кориснішим, ніж це буде в локальній мережі. Недоліки UDP можна значною мірою усунути, зробивши перевірку цілісності самостійно, але ви не можете витягнути функції з TCP, щоб зробити це швидше.
Маркс Томас

1
Вам потрібно згадати Наглса . Я завжди забуваю, що це першопричина, чому TCP злий (пакети буферів Nagle у клієнта / сервера, в основному "утримуючи" їх від вашої гри та вводячи додаткові затримки).
bobobobo

Існує кілька причин, чому слід використовувати UDP замість TCP, якщо затримка викликає занепокоєння. Якщо вам не байдуже затримка та / або ви здатні зробити достатньо прогнозування на стороні клієнта, то TCP може бути достатньо. Що стосується ігор у режимі реального часу. Забудьте про TCP.
Nuoji

6

Цілком прийнятно використовувати TCP замість UDP - якщо вимкнути алгоритм Nagle .

Після того, як ви вимкнете Nagle, ви отримаєте більшу частину швидкості UDP і зможете повністю провести гру реакції . Дійсно, я зробив таку гру, використовуючи TCP у Flash:

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

Сподіваюся, що це допомагає!


Неоперативний додаток за вашим посиланням, сер.
Інженер

Посилання повністю перекручене, сер. Я отримую тест сервера Apache.
Густаво Масьєль

4

Для FPS-ігор ми завжди використовуємо UDP. Особливо, якщо ви робите шутер з смикання, де пінг має значення.


4

Це залежить від виду гри.

Деякі ігри, такі як RTS, грають набагато краще за TCP і зазвичай використовують TCP весь час.

Справжня проблема TCP полягає в тому, що якщо ви отримуєте втрату пакету - навіть невелику кількість - тоді з'єднання «зупиняється», поки не відбудеться повторна передача. Операційна система не може доставити дані про замовлення в додаток (це порушує гарантії TCP, але також, TCP не показує меж кадру програми). Стойка з'єднання означає, що згодом надходять пізні дані. Але в (наприклад) FPS грі застарілі дані марні.

За допомогою UDP додаток може вибирати, що робити з даними про пізній або поза замовленням. Він може (і для такої гри, як FPS, як правило) ігнорувати старі дані та просто приймати останні. Іноді втрачений пакет взагалі не затримує наступні пакети. Якщо врешті-решт пакет приходить із затримкою, він може ігноруватися грою.


Зауважте, що для вашої реалізації потрібно буде обробляти аспект відкидання затримок пакетів, оскільки UDP трактуватиме її як отриману дейтаграму.
Гуванте

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 або ~ 14 кб накладних витрат UDP в секунду + 600 байт даних повідомлень.

Знову ми задаємо питання, наскільки життєво важливими є ці повідомлення, наскільки часто вони зустрічаються, і чи можна їх якимось чином зменшити, щоб зменшити накладні витрати?

Це просто на основі безлічі однобайтових повідомлень, як правило, ви робите щось зовсім інше, але, не знаючи, що надсилаються необроблені дані, важко довести будь-який спосіб, якщо TCP краще підходить до вашої ситуації, ніж UDP.

Отже, це буде працювати?

Що ж, якщо у вас типовий кадр в секунду, і позиція важлива (щоб уникнути обману або неправильних рішень), вам потрібно знати, що ваш мережевий потік є надійним, але 32 гравці кожного потоку, що 24 к + повідомлення байтів вперед і назад (так 768 КБ / s + messages) ... це приблизно 10 Мб / с широкосмугова лінія для окремих заголовків на основі надсилання принаймні 1 повідомлення на кадр від кожного клієнта всім іншим клієнтам через сервер.

Ви, очевидно, не будете кодувати ваш сервер і клієнта таким чином, і розміри повідомлень, швидше за все, будуть набагато більшими і, ймовірно, трохи рідшими, ніж 1 байт на кадр у більшості ситуацій, тому важко сказати, не бачачи реального світу приклад "це дані, які мені потрібно надіслати".

Моя справа

Я подзвонив у своєму випадку, що це розумний накладні витрати, але це базується на тому, як я будую свої потоки повідомлень, щоб у мене не було величезних накладних витрат порівняно з деякими проектами.

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

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

Інші міркування

Багато погано кодованих ігрових двигунів обробляють все на головній нитці на процесорі, тому процесору часто приділяється лише дуже мала кількість часу для обробки мережевого коду, гідна реалізація як сервісу, так і клієнта була б повністю асинхронізована і, можливо, штовхає і тягніть повідомлення партіями.

Є кілька хороших мережевих бібліотек, але, як видно тут, багато хто, здається, мають думку про те, що UDP - це "просто краще", добре враховуйте спочатку ваші потреби, і це може бути не так, і знайти бібліотеку, яка не відповідає Фактор у тому, що ви робите, може призвести до погано зашифрованої настройки TCP порівняно з варіантом UDP в тій же області (я просто кажу, що я це бачив, і тести навантаження підтвердили це).

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


2

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.