И все таки что же лучше для мобильных устройств TCP или UDP?

Question

[svavan]

Хотелось бы услышать мнения о плюсах и минусах обоих протоколов применительно к мобильным устройствам, например таким как GPS трекер, которые используют мобильные сети (чаще GPRS) для передачи информации.

UPD: Что будет с нагрузкой на сервер в случаях применения того или иного протокола?

Answer 1

[agmt]

Читаем их описание в википедии. Думаем, что есть GPS. Понимаем, что он должен как можно чаще слать мало информации, но если какая-то часть информации потеряется, то и хрен с ней — она уже не актуальна.

Comments

[JDima]

Не уверен, что «хрен с ней». Трек получится дырявый.

Важно понимать, что в случае UDP контроль доставки переносится на уровень приложения. То есть все решаемо.

[Владимир Дубровин]

Более того, в сетях с очень большой потерей пакетов TCP в принципе не выживет, а построить протокол поверх UDP который будет работать даже при 90% потере пакетов можно.

[svavan]

Да, сделать свою проверку поверх UDP не проблема. А данные которые не передались можно записать в архив и попробовать потом передать.

[agmt]

Учитывая скорость перемещения, шум, низкую частоту обновления данных gps, её более частое пропадание (по сравнению с gprs), трек должен получиться дырявый — интерполировать надо в любом случае. Складировать данные требуется лишь в случае обновления gps, но недоступности gprs. Протокол менять надо лишь в случае откровенно плохого качества gprs.

[svavan]

«Протокол менять надо лишь в случае откровенно плохого качества gprs.» — С какого на какой?

[agmt]

Если потерь будет много, то надо добавлять обратную связь.

Answer 2

[Владимир Дубровин]

UDP имеет смысл использовать в таких случаях:
1. На сервер будет отправлен единственный запрос и будет получен единственный ответ, который уберется в один пакет (передать данные проще чем установить TCP-соединение)
2. Идет поток данных в реальном времени, при этом в случае потери или задержки сетевого пакета, лучше вообще потерять эти данные чем заново отправлять (TCP соединение будет только мешать)
3. Планируются мультикастные реализации для этого протокола (TCP в принципе не годится)

Во всех остальных случаях лучше использовать TCP

Comments

[svavan]

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

Answer 3

[rustler2000]

Не зависит от терминала. Зависит от «приложения».
С TCP не получите ping/rtt, но легче «горизонтально» масштабировать сервера.
С UDP легче адаптироваться под реально плохие каналы, избежать чудес билинга(за перепосылку данных вам платить но сколько данных не дошло на TCP знает только его стэк), но будут сложности с прокси и nat.

Если о gps трекере, то яб делал на UDP. Накапливаеш трек, и когда данных под завязку для MTU (тут есть нюансы но для трэкера их можно не учитывать) отправляешь на сервер. Сервер же молчит пока не заметит дыры в треке (или раз в н пакетов или м минут) делает запрос на повтор интервала/ов. Клиент очищает пересылает данные и очищает трэк вплоть до первого запрашиваемого интервала(фактически это ACK).
Если надо лаг уменьшить (к примеру трэкер смотрят онлайн) то сервер просит трекер уменьшить «MTU» на х секунд (фактически это может быть полем в запросе на пересылку). На трэкере в трек писать и инфу о выключенном трэкере. Трэк хранить в файле исплльзуемом как ленту стримера, чтобы никаких fseek за исключением возврата в начало файла.

Comments

[svavan]

Спасибо за развернутый ответ. Я тоже склоняюсь к UDP.

[agmt]

Я бы сделал наоборот — о плохих сервер молчит, о хороших докладывает. Если клиент не дождался подтверждения за 30(+-) секунд, то перепосылает, дождался — очищает буфер. Новая координата появляется каждую секунду, занимает не больше 16 октетов.

[svavan]

Да именно так и предполагается. Еще можно ограничить количество «перепосыланий» чтоб устройство не «долбило» пакетами если например сервер банально отключен.

[agmt]

Небольшой запрос фичи: потестируйте разные варианты — забивать до MTU и посылать не больше N<<30 координат. Результаты будут весьма полезны, ибо писать ПО надо хорошо, а не как сейчас (твиттер пост с фото сейчас отправляет только в идеальных условиях).

[rustler2000]

Пересылка автоматом без запроса с сервера — прямая дорога в DDoS. Сервер отсылает запрос на пересылку только в ответ на полученный пакет.

Пакет на координату — низкая утилизация канала и заголовки пакетов оплачивать придется. Плюс большая загрузка для сервера.

Вместе с координатой необходимо качество и время. Если только координату пересылать то замучаетесь в трэк это клеить на сервере. Если качество не пересылать — то машины проходящие по тоннелям доставят вам радости вовремя привязки к дорогам.

[svavan]

Я бы хотел уточнить что речь идет о выборе между двумя протоколами. Работа по организации самого GPS трекинга пока не рассматриваем. Хотя все что вы написали конечно правильно и учитывается. Качество и время нужны по любому.

[agmt]

Время в принципе входит в координаты. Погрешность, пожалуй, нужна, да. Трафик я подразумевал безлимитный, потому и предлагал по малу слать.

Answer 4

[Alexander Yankovskiy]

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

Извините, если ошибаюсь, лучше объясните где не прав.

Comments

[svavan]

Делают по всякому. Чаще всего просто если не получилось передать пакет то его заносят в архив до лучших времен. А когда связь появится передать накопленное. Я пытаюсь тут выяснить насколько оправданно использовать всю «михину» TCP стека с таким каналом и таким небольшим объемом данных.

[agmt]

Меня смущает лишь то, что пакет размером 50 октетов передастся с заметно большей вероятностью, чем в 500, особенно в плохих условиях. А значит с каждым разом передать будет сложнее и сложнее. // Я сам слабо знаком с gprs, быть может он сам разбивает на маленькие пакетики и каждый перепосылает при ошибке, но если судить по реальным приложениям, то передать мегабайт заметно сложнее (а не просто дольше), чем 10кб.

[svavan]

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

[agmt]

Надо смотреть на спецификации GPRS. Где-то промелькнула информация, что лучше ограничить MTU на уровне 250..296.

Answer 5

[tgz]

Ну в мобильных то сетях сам бох велел sctp использовать :)

Comments

[agmt]

Ээээ? Зачем многоканальность?

[svavan]

Думаю sctp тут ненужно.

[tgz]

Я ни о какой многоканальности не говорил.
А где нужно sctp те кто мобильными сетями занимаются и так знают.