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

Подробней распишите задачу.
Если нужна более-менее гарантированная доставка пакета - TCP. Если устройство тупо шлет пакет каждую секунду, а на другом конце не обязательно получить 100% пакетов (допустим, достаточно перерисовывать координаты раз в 10 секунд) - можно и UDP использовать.

Т.к. трафик стоит денег, то мы не можем слать впустую пакеты, т.к. все считается. Поэтому я считаю, что необходимо использовать tcp, по крайне мере есть определенный процент вероятности, что пакет дойдет. данные отправляются раз в 30 сек или по событию - пройдено 100метров например.

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

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

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

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

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

P.S. Мы решаем сходную задачу (хоть и не трекер) - пока UDP, все от всех валится на один порт...

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

Ну, выбирал не я (у меня-то закладывается на выбор, TCP/UDP), тот, кто делал серверную часть, решил, что UDP ему обрабатывать проще...

- это не только ваша цель ))
я выбирал tcp сам. не особо парясь в стоимости. у меня пакеты умные и упакованые. если на бакс в месяц нашлепает то хороше.

больше внимания ИМХО питанию надо уделять ))) и защите входов. палят их постоянно. )) и джамеров накупили кучу. вабще жизни не дают.

Тут наверно сценарии применения имеют бОльшее значение чем нюансы протокола.

Работу напрямую с проприетарными серверными решениями как бы не рассматриваем в виду того что просто ничего о них не знаем и они часто могут скрывать элементарные, примитивные и нефункциональные решения.

А если посмотреть с какими открытыми сервисами могут работать трекеры то все довольно ясно.
Чтобы работать с Google maps или другими онлайн картами нужен протокол HTTP который работает поверх TCP.
Чтобы находить страницы с картами Google Maps нужен протокол DNS который базируется на UDP.
По UDP также работают клиенты точного времени.
Если нужна защита канала связи то повсеместно применяют SSL, а SSL требует TCP.
Если нужна закачка файлов на FTP или работа с почтовыми серверами то нужен TCP.
Однако если нужно получить канал связи между двумя модемами без фиксированных IP и без промежуточного выделенного для этой задачи сервера то надо применять UDP.
Также UDP применяется при использовании технологии тонелей.

Кстати, все это реализовано на вот таком многофункциональном трекере:
ARMGeoSpyder

А зачем собственно убеждать? Хотят UDP сделайте UDP.

в трекере лучше использовать UDP протокол. меньше оверхеда в пакетах.

Если пакеты "умные и правильные" (простите за цитирование), то это не проблема. Вообщем, программист-технический директор заказчика захотел Udp, так и сделали уже. Всем спасибо за комментарии.

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

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

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

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

Необходимо только принять во внимание, что хоть RFC 4787 и дает рекомендации по поведению NAT, реально существует 3 варианта реализации функциональности NAT, каждый из которых имеет свои особенности и ограничения. Вы описали только первый, который применяется в методе "Hole Punching" для так называемых NAT Traversal Techniques.
Это как раз и учитывается при построении пиринговых коммуникаций (P2P).
Особенно это актуально для мобильной связи, когда оператор GSM часто может меняться.

ИМХО если варианты равноценны, то выбор одного из них вопрос исключительно религиозный. Еще раз повторю если нет весомых "против" делайте так как хочет заказчик. Ну вот представьте себе ситуацию - уламали вы заказчика на TCP, а тут проблемы выплыли и заказчик вам говорит "вы же мне обещали!!!!".

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