UDP vs TCP Опции

[Arthur_Sh]

Господа, возникла такая ситуация. Технический представитель заказчика в конструкции gps-gsm трекера предлагает использовать udp протокол, мы же склоняем его к использованию tcp. не могли бы вы привести факты, плюсы-минусы с вашей точки зрения, по выбору или udp или tcp протокола? заранее спасибо за конструктивную информацию.

[av-master]

даешь каждой машине по трекеру )

Я держал раньше 2 конекта один UDP второй TCP.
основная масса шла по UDP.

потом плюнули вырезали все лишнее перевели в Бинарник. сжали что можно. проработали протокол. и отставили только TCP /
к тому-же трафик уже конкретно подешевел.

[Arthur_Sh]

даешь каждой машине по трекеру )

Я держал раньше 2 конекта один UDP второй TCP.
основная масса шла по UDP.

потом плюнули вырезали все лишнее перевели в Бинарник. сжали что можно. проработали протокол. и отставили только TCP /
к тому-же трафик уже конкретно подешевел.

Да я все это тоже понимаю, но их технический директор уперся в udp и все логичные доводы просто игнорирует. нам то по большому счету все одно, есть реализованные протоколы и на udp и на tcp, но ведь хочется людям показать, как правильно все таки.
P.S. у нас именно такая цель и стоит - ДАЕШЬ КАЖДОЙ МАШИНЕ ПО ТРЕКЕРУ

[Oldring]

нам то по большому счету все одно, есть реализованные протоколы и на udp и на tcp, но ведь хочется людям показать, как правильно все таки.

А как на самом деле "правильно"?

UDP - он более низкоуровневый. На нем можно реализовать всё, что позволяет TCP, особенно это несложно, если пакеты небольшие и фиксированного размера. TCP, с другой стороны, гарантирует доставку пакета в наиболее распространенных сценариях. Но на ненадежных каналах этот сервис может сыграть злую шутку: пакеты, нагенерированные источником в реальном времени, забьют канал. Да и переоткрытие TCP соединения в случае разрыва связи тоже требует специальной обработки пользователем. Поэтому сервисы реального времени обычно всё-таки делают на UDP, реализуя мягкую обработку потерь пакетов.

[AlexandrY]

А как на самом деле "правильно"?

UDP - он более низкоуровневый. На нем можно реализовать всё, что позволяет TCP, особенно это несложно, если пакеты небольшие и фиксированного размера. TCP, с другой стороны, гарантирует доставку пакета в наиболее распространенных сценариях. Но на ненадежных каналах этот сервис может сыграть злую шутку: пакеты, нагенерированные источником в реальном времени, забьют канал. Да и переоткрытие TCP соединения в случае разрыва связи тоже требует специальной обработки пользователем. Поэтому сервисы реального времени обычно всё-таки делают на UDP, реализуя мягкую обработку потерь пакетов.

IMHO, но UDP интересен прежде всего логикой его обработки NAT-ами провайдеров.
А именно тем, что они пропускают к модему внешние пакеты с IP отличных от того на который прошел первый пакет от модема. Это сильно упрощает межмодемное общение.
Может только эту особенность и имел в виду заказчик. А особенности протокола тут не причем.

Ну а утверждать что доморощенные решения на UDP вдруг окажутся эффективнее десятки лет совершенствовавшегося TCP стека немного не логично.
Даже те протоколы тоннелей которые сидят на UDP типа PPTP работают в GSM сетях гораздо хуже чем TCP .