Не приймайте просто "так чи ні, тому що я це сказав", введіть тут відповідь, оскільки, можливо, ви відкриваєте себе перед тим, що вам доведеться боротися з купою проблем з 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 гравці на гру (або будь-які обмеження у вас).