Обмен данными TCP или UDP ?

Status
Not open for further replies.

vladgul

Турист
Что лучше выбрать для скоростного обмена данными в условиях прерывающегося соединения и не очень быстрых линий связи?

TCP с постоянной проверкой наличия соединения (не факт, что "просечет" обрыв только таймауты использовать),
или
UDP, но с собственной организацией подтверждений приема/получения сообщения?
 

a101010

Турист
Смотря что и как ты хочешь отправлять.
если не особо важные данные то можно UDP, а если данные с пожарных датчиков - то однозначно TCP. :)
 

vladgul

Турист
И почему обязательно с TCP, если я сам организую проверку и подтверждение приема? Т.е. данные однозначно не потеряются "по дороге".

P.S. Про пожарные датчики почти в точку :)
 

Veda

Бывалый
Свой / Own
Что лучше выбрать для скоростного обмена данными в условиях прерывающегося соединения и не очень быстрых линий связи?

TCP с постоянной проверкой наличия соединения (не факт, что "просечет" обрыв только таймауты использовать),
или
UDP, но с собственной организацией подтверждений приема/получения сообщения?
тут и выбора нет, если верить формулировке!
Обмен данными подразумевает установление сессии, а с учётом слабого канала, да ещё и прерывающейся связи вообще странно что был задан такой вопрос!

А вот о том как тюнить tcp в данном случае стоит крепко подумать, да и IP ли это должен быть - если есть возможность выбора.
 

Veda

Бывалый
Свой / Own
И почему обязательно с TCP, если я сам организую проверку и подтверждение приема? Т.е. данные однозначно не потеряются "по дороге".

P.S. Про пожарные датчики почти в точку :)
Пока писал предидущий пост появилась эта информация :))

То-есть всё же в данном случае односторонний поток данных фактически получается? От "датчиков" к некоему польту - верно я понимаю?
 

a101010

Турист
И почему обязательно с TCP, если я сам организую проверку и подтверждение приема? Т.е. данные однозначно не потеряются "по дороге".
Ну как говорится - "хозяин барин", но я бы, например, меньше всего задумывался о транспорте, там и без меня все технологии уже давным-давно продуманы, и реализованы в множестве компонентов, а сосредоточился бы на на чем-нибудь более важном. Например, на архитектуре всей системы, с целью исключения самого слабого звена (плохого канала передачи данных).
 

nickneykov

Турист
Я тоже за ТСР, но если вы так отвечаете, то ... почему спрашиваете?
 

vladgul

Турист
Пока писал предидущий пост появилась эта информация )

То-есть всё же в данном случае односторонний поток данных фактически получается? От "датчиков" к некоему польту - верно я понимаю?
23.07.10 12:20
Не совсем. Данные от датчиков собираются и анализируются автономной системой, а потом уже передаются на комп. Причем канал передачи
RS232 (COM). Эти данные собираются программой драйвером и уже потом
идет обмен (о котором и идет речь в этой теме) с программой сервером.

Вопрос возник не случайно, в нормальных условиях по TCP все работает как положено.
Только недавно возникла ситуация: случайно сильно пережали сетевой кабель UTP. После этого вроде сеть работает, но ... программа на компах, которые были подключены по этой линии связи практически не работала, и все в целом было похоже на DDOS атаку. TCP в данном случае не справлялся. Как мы поняли потом, пытаясь запросить повторно "кривые" пакеты TCP подвешивал связь местами намертво.
Думаю, что в случае с UDP такого просто не было. Т.е. принимая в очередной раз "кривые" данные (контрольные суммы то никто не отменял :)) можно было бы программно оценить, что присутствуют огромные проблемы при передаче.
В случае с TCP эти "проблемы" берет на себя протокол, но при этом "программа", которая с ним работает не знает о проблемах.

Описанную выше ситуацию смогли определить только через 2 дня и то практически случайно. Первоначально думали на вирусы.

Отсюда и был задан вопрос, с учетом запаса "прочности" какой все таки протокол лучше использовать, поскольку с UDP тоже не все так гладко.
 

a101010

Турист
Не совсем. Данные от датчиков собираются и анализируются автономной системой, а потом уже передаются на комп. Причем канал передачи
RS232 (COM). Эти данные собираются программой драйвером и уже потом
идет обмен (о котором и идет речь в этой теме) с программой сервером.
Еще одни совет. Если очень критично, то для контроля работоспособности сети (точнее оборудования) используйте SNMP. На практике знаю, что скорость локализации проблем практически мгновенная. :5:
 

Alder_

Турист
UDP позволяет относительно легко проходить NATы

Добавлено через 3 минуты
Делал свою реализацию протокола на UDP - главная проблема в поддержании оптимальной скорости отправки данных, чтобы было мало потерь пакетов и канал не простаивал в то же время.

Добавлено через 5 минут
Для c++ есть библиотека Google Libjingle в которой реализован собственный надежный протокол PseudoTCP на основе UDP.
 
Last edited by a moderator:

XNeo

Турист
Если у вас 80% потерь пакетов в сети при использовании ТСР то при переходе на UDP их 80% и останется. От этого не изменится абсолютно ничего. А вот свой "ведлсипед" для организации надёжного обмена обойдётся достаточно дорого.
Если у вас проблемы возникают изза DDoS тогда может поработать в направлении защиты а не прыгать между протоколами? Атаковать UDP тоже можно достаточно неплохо :)
 

glh

Турист
Рассмотрите для решения описываемой проблемы ZeroMQ.
Или возьмите на вооружение MQTT протокол.

ZeroMQ - несмотря на MQ в названии, библиотека (нольMQ, без очередей), реализующая IPC взаимодействие на базе IP.
Предлагает инфраструктурные вещи, может рассматриваться как еще один сетевой уровень.
Ну там модель Publisher-Subscriber.
Что обычно изобретают, когда выбирают сокеты для ваимодействия.
Позволяет организовать быстрый обмен сообщениями по различным протоколам: между удаленными компами - на основе tcp, а так же udp (но с гарантией доставки!), реализует межпроцессное взаимодействие и внутрипроцессное (между потоками).
При реализации на основе tcp не надо париться по поводу частичного заполнения буферов сокетов: сообщение доставляется полностью. Разные варианты схем взаимодействия.
google

MQTT - протокол, ориентирован на быструю и надежную доставку упакованных в бинарный конверт пакетов.
Пришел из интернета-для-железяк Internet of Things, IoT.
Нужен сервер, реализующий протокол.
Свободных - в достаточном количестве.
google
 

heilong

Турист
Вообще во избежании потерь пакетов на ненадежном участке(линия больше 100 метров и д.р.) уменьшают размер пакета(MTU) с 1500 до 576 байт. Скорость просаживается, но все работает.
 
Status
Not open for further replies.
Top