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

[vladgul]

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

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

 

[xpert66]

Я бы использовал UDP, чисто субъективно.

 

[a101010]

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

 

[vladgul]

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

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

 

[Nofire]

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

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

тут и выбора нет, если верить формулировке!
Обмен данными подразумевает установление сессии, а с учётом слабого канала, да ещё и прерывающейся связи вообще странно что был задан такой вопрос!

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

 

[Nofire]

И почему обязательно с 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:

 

[taishy]

Еще, как вариант посмотрите в сторону RS-485

 

[Alder_]

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

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

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

 

[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 байт. Скорость просаживается, но все работает.

 

[emale]

Понятие "обмен данными" очень размытое.
Если имелось в виду собирание данных с датчиков (посылка текущих данных в одну сторону). то ничего лучше не найти, чем просто периодическая посылка инфы с датчиков в виде UDP пакетов. Пропажа пары пакетов ничего не даст, а поврежденные пакеты будут отбрасываться на уровне UDP checksum. По длительному отсутсвию пакетов судить о пропаже устройства из сети. Минус один - ограниченный размер UDP пакета - 1400 байт, если нужно больше данных, придется распихивать по нескольким пакетам

 

[kolobok16]

Однозначно TCP! UDP это не обмен данными, это отправка данных по ветру. Хотя если вам чисто за нагрузкой следить или там данные посылать потоком, то можно.

 

[bpost]

UDP = негарантированная доставка. Для ответственных потоков данных не подходит.

 

[zmarsik]

TCP в данном случае не справлялся. Как мы поняли потом, пытаясь запросить повторно "кривые" пакеты TCP подвешивал связь местами намертво.

Это не TCP сеть клал, скорее у Вас физичиски UpLink на коммутаторе(на этом куске) то появлялся то пропадал.

 

[Pashaaaa]

Какое кол-во данных планируется посылать, и на какое кол-во клиентов,
UDP хорош своей непривязаностью к конкретному клиенту, но сильно засоряет сеть, TCP более узскйи в плане посылки и буфера