Господа, возникла такая ситуация. Технический представитель заказчика в конструкции 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 .