UDP vs TCP

 
+
-
edit
 

Balancer

администратор
★★★★★
Навеяно дискуссией на ЛОРе.

Насколько, всё же, реально оправдан UDP?

Ибо усложнение будет заметное (нужно помнить отосланные пакеты и ждать их подтверждения) + прирост трафика (пакеты подверждения).
 

Murkt

Pythoneer
★★★
А UDP бегает гораздо быстрее? Но ведь он не гарантирует порядок пакетов... Это ахтунг из ахтунгов.
[team Їжачки - сумні падлюки]  
+
-
edit
 

Balancer

администратор
★★★★★
Вот потому и спор :)

geek в ЛОРовском топике (можешь почитать) утверждает, что FPS-отзывчивость может быть только на UDP. И, в общем, он прав (порядок пакетов тут не столь важен, если к вопросу подходить вдумчиво, скажем, при беге, если придёт "старый" moveto при наличии более нового, то он просто проигнорирыется. Не дохождение пакетов решается подтверждением о получении пакета) - но для FPS :) Сразу возникает вопрос, возможна ли MMOFPS, но и тут был откопан ответ - World War II Online - Wikipedia, the free encyclopedia

У них именно MMOFPS и именно на UDP. При чём разработчики как раз плакались, что на UDP надо было делать с самого начала - 404 Not Found

Но UDP - это, как я уже говорил, существенное усложнение системы и затраты ресурсов.

И, как назло, это вопрос, который лучше всего решать изначально. Ибо это скелет всей системы :D

Как вариант - два потока данных. TCP для всего, UDP для требующего быстрой реакции (вводить можно позже). Кстати, вот голос как раз можно гнать по UDP - там недохождение не так критично :)
 
UA MorbidAngel #03.07.2007 14:48  @Murkt#03.07.2007 12:15
+
-
edit
 

MorbidAngel

разработчик L2J Fortress
★★★
Муркт> А UDP бегает гораздо быстрее? Но ведь он не гарантирует порядок пакетов... Это ахтунг из ахтунгов.

Сохранить хронологию пакетов - легко, но в пакеты нужно вшивать идентификатор, например процессорное время потраченное клиентом, и соответственно на сервере в клиентском потоке хранить время последнего не "просроченного" пакета
 
+
-
edit
 

Balancer

администратор
★★★★★
Очень дельная мысль в пользу UDP (с ЛОРа):

>Подтверждение не обязательно, достаточно ввести в пакет понятие sequence и внутреннюю команду на replay_sequence

Тогда, действительно. Клиент (или сервер) получает пакет. Смотрит номер N. Если предыдущий номер пакета по этому соединение не равен N-1, то перезапрашивает пропавший пакет. В этм случае - да, будет определённый лаг. Но как правило на нормальном соединении их не будет. Не будет и пакетов подтверждения со всеми вытекающими.

Получается легко и быстро.
 
+
-
edit
 

Balancer

администратор
★★★★★
Всё, UDP отменяется.

"Серые" клиенты не смогут получать по нему данные с сервера.

...

Хотя ещё возможен вариант, когда клиент соединён с сервером в два потока и отсылает ему данные по UDP, а получает - по TCP.

stave

разработчик OpenWorlds
Почему UDP не подошел? Сейчас просто участвую в сходном проекте, много материала перерыл. Кто что говорит, или юдп для быстрых данных/тсп для медленных и важных, кто про юдп с надстройками.
 
+
-
edit
 

Balancer

администратор
★★★★★
Забавно, что никому в прошлых спорах в голову не пришёл вариант совмещения протоколов. Для «медленной активности» можно использовать более простой и надёжный TCP. А для отдельных зон (FPS-игровых и т.п.) вводить параллельный или замещающий UDP.
+
-
edit
 

Mishka

модератор
★★★★

Balancer> Забавно, что никому в прошлых спорах в голову не пришёл вариант совмещения протоколов. Для «медленной активности» можно использовать более простой и надёжный TCP. А для отдельных зон (FPS-игровых и т.п.) вводить параллельный или замещающий UDP.

Когда в UDP введётся понятие sequence, будет упорядочивание, определение потерянных пакетов, то это будет уже TCP (надо только окна приделать ещё) со всеми overheads TCP. Только будет реализован на уровне сервера, а не ОС. У UDP, собственно, два важных преимущества — он пакетный и гарантируюется, что пакет прибудет целиком. Ну и применятся должен там, где потеря пакета пофигу. Скорость UDP только кажущаяся. Пакеты выплёываются на провода и про них забывают, а TCP ждёт ответов в пределах окна и новые не выплёвывает, если окно полное. Если самому ждать, то задержки те же самые. Окно у TCP можно увеличить, тогда он будет плевать быстрее. Но и перепосылки будут крупнее, если что-то сломается в пределах окна по дороге.

А синхронизация UDP c TCP будет очередной головной болью, бо даже маршруты у них могут быть разные. Не говоря про очереди на промежутоных раутерах. Если хочеться совмещения, то посмотри на новый SCTP, который тоже пакетный, но с надёжностью TCP (порядок, доставка и прочее), а ещё позволяет организовывать "подканалы".

AXT

инженер вольнодумец
★★★
Balancer> Всё, UDP отменяется.
Balancer> "Серые" клиенты не смогут получать по нему данные с сервера.

Не понял. Вроде же NAT для UDP обычно работает в обе стороны? Играют же люди в ажно Quake 3 из-под NAT, хотя там протокол только UDP с собственноручной гарантированной доставкой поверх?

Собственно, даже: UDP hole punching - Wikipedia, the free encyclopedia

Т.е. можно после начала разговора с сервером пробросить точка-точка между клиентами. Да, это хак в некотором смысле, но ведь работает же!
 

AXT

инженер вольнодумец
★★★
Mishka> Скорость UDP только кажущаяся. Пакеты выплёываются на провода и про них забывают, а TCP ждёт ответов в пределах окна и новые не выплёвывает, если окно полное. Если самому ждать, то задержки те же самые.

Это смотря как формулировать "скорость" :) У того же Quake протокол сделан с целью минимизации задержки в цепочке "игрок что-то сделал, сервер обработал, игрок увидел результат". Поэтому там протокол сделан так, что флудит беспощадно в пределах заявленной пропускной способности канала, зато хоть один дошедший пакет продвигает состояние игры до времени его отсылки. И повторные посылки потерянных IP пакетов в стиле TCP характеристики протокола только ухудшат.
 
+
-
edit
 

Balancer

администратор
★★★★★
Mishka> Когда в UDP введётся понятие sequence, будет упорядочивание, определение потерянных пакетов, то это будет уже TCP

Ну не до такой же степени :) Вон, как выше вариант флуда упоминался. Нажимает игрок кнопку стрельбы и клиент начинает долбить сервер серией пакетов, пока от сервера к нему не пробьётся пакет «выстрел получил, хватит флудить» :) Под sequence подразумевается работа не с конкретными пакетами, нехай пропадают, а с конкретными действиями. Если мы уже обрабатываем пакет «перемещение» под номером N (и ответили клиенту, чтобы заткнулся), то игнорируем все повторные перемещения под этим номером, но отменяем предыдущее действие и начинаем новое, если получим пакет под номером N+1.

Mishka> А синхронизация UDP c TCP будет очередной головной болью

А она не требуется. Как я писал, во-первых, UDP-вариант в отдельных зонах может быть вообще замещающим, во-вторых, никто не мешает их использовать параллельно по принципу «кто раньше пришёл, того и тапки».
+
-
edit
 

Mishka

модератор
★★★★

Balancer> Ну не до такой же степени :) Вон, как выше вариант флуда упоминался.
А ты подумай, с какой стати он дойдёт до сервера быстрее? :) Он не дойдёт быстрее. А только клиенту попроще, он не дожидается окончания вывода. Дык, TCP тоже не обязан. Можно нон блокинг поставить.
AD Реклама Google — средство выживания форумов :)
+
-
edit
 

Balancer

администратор
★★★★★
Mishka> А ты подумай, с какой стати он дойдёт до сервера быстрее? :)

Ответь, почему для FPS годится только UDP-based, а TCP-based сильно тормозит? :)
 26.0.1410.6426.0.1410.64

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru