Чи має сенс використовувати одночасно і TCP, і UDP?

Після прочитання Чи UDP все ще кращий, ніж TCP, для важких ігор в режимі реального часу? , Мені цікаво, чи є сенс використовувати одночасно і TCP, і UDP, але для різних речей:

• TCP для надсилання інформації, що надсилається нечасто, але має бути гарантовано надійною.
  Такі як оновлення очок, ім’я гравця або навіть стан увімкнення / вимкнення світла в ігровому світі.

• UDP для передачі інформації, яка постійно оновлюється і може періодично втрачатися, оскільки новіша інформація завжди в дорозі.
  Такі як положення, обертання тощо.

Це розумна ідея? Які можливі недоліки?
Чи є кращі способи впоратися з цим?

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

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

Прикладом цього є бібліотека Enet з відкритим кодом , її основною особливістю є необов'язково надійна доставка на замовлення пакетів через UDP.

Ось цитата Сема Янсена з коментаря на gafferongames.com :

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

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

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

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

Щоб відповісти на ваше запитання:

Мені цікаво, чи є сенс використовувати одночасно і TCP, і UDP, але для різних речей [...]

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

• TCP для надсилання інформації, що надсилається нечасто, але має бути гарантовано надійною. Такі як оновлення очок, ім’я гравця або навіть стан увімкнення / вимкнення світла в ігровому світі.

Використовуючи і TCP, і UDP, завжди слід віддавати перевагу надсилати якомога більше через UDP і якомога менше через TCP.

Тепер я запитую вас у цьому: чи справді потрібно надсилати рахунок, ім'я гравця та стан світла над TCP? Хоча це правда, що вам потрібно отримати ці дані в кінцевому підсумку, чи правда, що вам потрібно отримувати ці дані строго в порядку та точно один раз?

Напевно, ні.

UDP добре працює в цих випадках, а Quake 3 - хороший приклад того, як це зробити.

То який хороший приклад TCP поряд з UDP? Ну, подумайте про чат гри. Оновлення цього чату (тобто нові рядки тексту) потрібно надсилати як надійно, так і строго в порядку. Таким чином, TCP добре підходить.

Це розумна ідея?

• Так

Які можливі недоліки?

• Втрата пакетів, більша складність коду, ще одне підключення для управління == більше шансів на відключення, тайм-аути, винятки, що завгодно ...

Чи є кращі способи впоратися з цим?

• Використовуйте існуючу надійну бібліотеку UDP. Два найпопулярніші: Lidgren Network (C #), RakNet (C ++). З досвіду можу сказати, що Lidgren дуже простий у використанні, швидкий і надійний.

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

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

Одним із варіантів є лише відкрити тимчасове підключення TCP під час передачі даних та негайно закрити його. Це зробить транзакції повільніше, відкриття tcp Connection є досить «дорогим» процесом. Як завжди, справа в тому, щоб створити надійну систему з самого початку, щоб дозволити велике зростання.