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

  • Автор темы vladgul
  • 5847
  • Обновлено
  • 12, Jul 2010
  • #1
Что лучше выбрать для скоростного обмена данными в условиях прерывающегося соединения и не очень быстрых линий связи?

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

или

UDP, но с собственной организацией подтверждений приема/получения сообщения?

vladgul


Рег
27 Dec, 2009

Тем
7

Постов
16

Баллов
86
  • 22, Jul 2010
  • #2
Смотря что и как ты хочешь отправлять. если не особо важные данные то можно UDP, а если данные с пожарных датчиков - то однозначно TCP.
 

a101010


Рег
15 Mar, 2010

Тем
4

Постов
34

Баллов
74
  • 23, Jul 2010
  • #3
И почему обязательно с TCP, если я сам организую проверку и подтверждение приема? Т.е. данные однозначно не потеряются "по дороге". P.S. Про пожарные датчики почти в точку
 

vladgul


Рег
27 Dec, 2009

Тем
7

Постов
16

Баллов
86
  • 23, Jul 2010
  • #4
vladgul, post: 719527:
Что лучше выбрать для скоростного обмена данными в условиях прерывающегося соединения и не очень быстрых линий связи?

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


тут и выбора нет, если верить формулировке!

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

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

Veda


Рег
12 May, 2005

Тем
3

Постов
28

Баллов
58
  • 23, Jul 2010
  • #5
vladgul, post: 719530:
И почему обязательно с TCP, если я сам организую проверку и подтверждение приема? Т.е. данные однозначно не потеряются "по дороге".

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



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

Veda


Рег
12 May, 2005

Тем
3

Постов
28

Баллов
58
  • 23, Jul 2010
  • #6
vladgul, post: 719530:
И почему обязательно с TCP, если я сам организую проверку и подтверждение приема? Т.е. данные однозначно не потеряются "по дороге".
Ну как говорится - "хозяин барин", но я бы, например, меньше всего задумывался о транспорте, там и без меня все технологии уже давным-давно продуманы, и реализованы в множестве компонентов, а сосредоточился бы на на чем-нибудь более важном.

Например, на архитектуре всей системы, с целью исключения самого слабого звена (плохого канала передачи данных).
 

a101010


Рег
15 Mar, 2010

Тем
4

Постов
34

Баллов
74
  • 30, Jul 2010
  • #7
Пока писал предидущий пост появилась эта информация )

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

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

Причем канал передачи

RS232 (COM). Эти данные собираются программой драйвером и уже потом

идет обмен (о котором и идет речь в этой теме) с программой сервером.

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

Только недавно возникла ситуация: случайно сильно пережали сетевой кабель UTP.

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

TCP в данном случае не справлялся.

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

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

В случае с TCP эти "проблемы" берет на себя протокол, но при этом "программа", которая с ним работает не знает о проблемах.

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

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

vladgul


Рег
27 Dec, 2009

Тем
7

Постов
16

Баллов
86
  • 30, Jul 2010
  • #8
vladgul, post: 719535:
Не совсем. Данные от датчиков собираются и анализируются автономной системой, а потом уже передаются на комп. Причем канал передачи
RS232 (COM). Эти данные собираются программой драйвером и уже потом
идет обмен (о котором и идет речь в этой теме) с программой сервером.
Еще одни совет. Если очень критично, то для контроля работоспособности сети (точнее оборудования) используйте SNMP. На практике знаю, что скорость локализации проблем практически мгновенная. :5:
 

a101010


Рег
15 Mar, 2010

Тем
4

Постов
34

Баллов
74
  • 27, Mar 2014
  • #9
UDP позволяет относительно легко проходить NATы
Делал свою реализацию протокола на UDP - главная проблема в поддержании оптимальной скорости отправки данных, чтобы было мало потерь пакетов и канал не простаивал в то же время.
Для c++ есть библиотека Google Libjingle в которой реализован собственный надежный протокол PseudoTCP на основе UDP.
 

Alder_


Рег
21 Oct, 2006

Тем
0

Постов
3

Баллов
3
  • 19, Apr 2014
  • #10
Если у вас 80% потерь пакетов в сети при использовании ТСР то при переходе на UDP их 80% и останется.

От этого не изменится абсолютно ничего.

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

XNeo


Рег
14 Aug, 2004

Тем
2

Постов
11

Баллов
31
  • 20, Apr 2014
  • #11
Рассмотрите для решения описываемой проблемы ZeroMQ. Или возьмите на вооружение MQTT протокол. ZeroMQ - несмотря на MQ в названии, библиотека (нольMQ, без очередей), реализующая IPC взаимодействие на базе IP. Предлагает инфраструктурные вещи, может рассматриваться как еще один сетевой уровень. Ну там модель Publisher-Subscriber. Что обычно изобретают, когда выбирают сокеты для ваимодействия.

Позволяет организовать быстрый обмен сообщениями по различным протоколам: между удаленными компами - на основе tcp, а так же udp (но с гарантией доставки!), реализует межпроцессное взаимодействие и внутрипроцессное (между потоками).

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

Разные варианты схем взаимодействия.
google

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

. Нужен сервер, реализующий протокол. Свободных - в достаточном количестве.
google
 

glh


Рег
13 Jan, 2014

Тем
0

Постов
1

Баллов
1
  • 11, Nov 2014
  • #12
Вообще во избежании потерь пакетов на ненадежном участке(линия больше 100 метров и д.р.) уменьшают размер пакета(MTU) с 1500 до 576 байт. Скорость просаживается, но все работает.
 

heilong


Рег
07 Jun, 2004

Тем
0

Постов
1

Баллов
1
  • 07, Dec 2014
  • #13
Понятие "обмен данными" очень размытое. Если имелось в виду собирание данных с датчиков (посылка текущих данных в одну сторону). то ничего лучше не найти, чем просто периодическая посылка инфы с датчиков в виде UDP пакетов.

Пропажа пары пакетов ничего не даст, а поврежденные пакеты будут отбрасываться на уровне UDP checksum.

По длительному отсутсвию пакетов судить о пропаже устройства из сети.

Минус один - ограниченный размер UDP пакета - 1400 байт, если нужно больше данных, придется распихивать по нескольким пакетам
 

emale


Рег
18 Apr, 2008

Тем
0

Постов
6

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

kolobok16


Рег
08 Dec, 2014

Тем
0

Постов
4

Баллов
4
  • 07, Jan 2015
  • #15
TCP в данном случае не справлялся. Как мы поняли потом, пытаясь запросить повторно "кривые" пакеты TCP подвешивал связь местами намертво.
Это не TCP сеть клал, скорее у Вас физичиски UpLink на коммутаторе(на этом куске) то появлялся то пропадал.
 

zmarsik


Рег
23 Aug, 2014

Тем
0

Постов
10

Баллов
10
  • 16, Jan 2015
  • #16
Однозначно TCP, иначе растеряете свои данные по дороге, и они до Вас не доберутся. ЗЫ, столкнулся как в телеметрии с задачей. Ну его этот UDP
 

MAD_EVAL


Рег
05 Aug, 2014

Тем
0

Постов
5

Баллов
5
  • 23, Jan 2015
  • #17
вообще то tcp оно вроде как круто. но всетаки наверное надо на один уровень вверх глянуть
 

dr_nil


Рег
02 Dec, 2010

Тем
1

Постов
6

Баллов
16
  • 07, Jul 2016
  • #18
Какое кол-во данных планируется посылать, и на какое кол-во клиентов, UDP хорош своей непривязаностью к конкретному клиенту, но сильно засоряет сеть, TCP более узскйи в плане посылки и буфера
 

Pashaaaa


Рег
22 Feb, 2007

Тем
1

Постов
17

Баллов
27
  • 11, Jul 2016
  • #19
vladgul, post: 719527:
UDP, но с собственной организацией подтверждений приема/получения сообщения?
так это и есть реализация TCP. Смысл в слабых и неустойчивых сетях посылать UDP пакеты, которе эту сеть еще больше будут нагружать
 

AndyCrow


Рег
03 Nov, 2009

Тем
2

Постов
10

Баллов
30
  • 30, Jul 2016
  • #21
In the case of slow TCP. But excellent stability. Sending the order comes. For UDP faster. There is no guarantee that your data. It does not come as a continuous data or send the order form. Mainly used in games or real-time streaming video.
 

yyjksw


Рег
17 Jul, 2008

Тем
0

Постов
13

Баллов
13
  • 02, Aug 2016
  • #22
Ну ок, используешь ты UDP, как тогда сказать датчику переслать данные заново, в случае если не сошлась контрольная сумма ?
 

Andrik7503


Рег
19 Jul, 2016

Тем
0

Постов
6

Баллов
6
  • 03, Aug 2016
  • #23
Andrik7503, post: 719563:
Ну ок, используешь ты UDP, как тогда сказать датчику переслать данные заново, в случае если не сошлась контрольная сумма ?
Какому датчику
 

LeshaRB


Рег
11 Jun, 2007

Тем
5

Постов
110

Баллов
160
  • 03, Aug 2016
  • #24
LeshaRB, post: 719564:
Какому датчику
Ну хорошо, назовем это обобщенно источник данных.
 

Andrik7503


Рег
19 Jul, 2016

Тем
0

Постов
6

Баллов
6
  • 03, Aug 2016
  • #25
Andrik7503, post: 719565:
Ну хорошо, назовем это обобщенно источник данных.
Послать ему запрос на повторную отправку данных?
 

LeshaRB


Рег
11 Jun, 2007

Тем
5

Постов
110

Баллов
160
  • 04, Aug 2016
  • #27
LeshaRB, post: 719566:
Послать ему запрос на повторную отправку данных?
Ну в принципе согласен. Здесь опять же через что ? TCP или UDP ? Надо еще смотреть что длинее - данные от источника или же запрос к ниму. Ну вопчем реализуемо и на том и на этом.
 

Andrik7503


Рег
19 Jul, 2016

Тем
0

Постов
6

Баллов
6
  • 28, Aug 2016
  • #28
LeshaRB, post: 719566:
Послать ему запрос на повторную отправку данных?
как узнать если пакет малый то дошел ли он ? если большой то надо изобретать велосипед .. по повторным отправкам .. и частям которые нужны .. что походу и делает ТСП так что юзать УДП в расчете на ошибки .. смысла нет ..
 

isam_os


Рег
28 Aug, 2016

Тем
0

Постов
2

Баллов
2
  • 15, Sep 2016
  • #29
TCP лучше, в том плане, что голова о ARP записях не болит и доставка гарантирована. В UDP нужно будет думать об квитанциях и повторной отправке. И через свитч UDP хуже работает иногда.
 

Keoda


Рег
19 Nov, 2014

Тем
1

Постов
18

Баллов
28
  • 26, Sep 2016
  • #30
скоростного обмена данными в условиях прерывающегося соединения
1. уже после фразы "прерывающегося соединения" можно забыть про UDP.

По ходу автор не совсем понимает выполняемую задачу этого протокола. 2. а что значит скоростной обмен ? :-) А какие есть обмены ?))))) реально бред.

Уже написали бы в крайнем случае.

что есть такая-то сеть c такой пропускной способностью, с такими-то узлами и параметрами, передавать планируется то-то и то-то.... как правильно программно организовать обмен информацией в такой сети.
 

fets


Рег
04 Oct, 2011

Тем
1

Постов
6

Баллов
16
  • 06, Dec 2016
  • #31
Как только усложнится протокол обмена UDP станет большим гемороем. Однозначно "медленно (???)", но уверенно TCP.
 

test1c


Рег
25 Jul, 2010

Тем
1

Постов
23

Баллов
33
  • 08, Dec 2016
  • #32
Не требовательный к постоянному коннекту протокол HTTP тоже работает на TCP. Ну и мне кажется что вообще идет тенденция отказа от UDP.
 

test1c


Рег
25 Jul, 2010

Тем
1

Постов
23

Баллов
33
  • 30, Dec 2016
  • #33
Приведу пример в пользу UDP.

Два устройства обмениваются данными на высокой скорости.

Изначально использовали TCP протокол.

Если нормальная сеть и приемник НИКОГДА не отваливается, то все нормально.

Если вдруг приемник по каким-либо причинам перестал принимать пакеты (например, отвалился порт) - беда, сеть забивается перезапросами и все виснет.
В итоге перешли на UDP, контроль передачи данных отдали на откуп ПО. Иногда бывают проблемы, но это не сказывается на работе всей сети
 

Label1979


Рег
24 Oct, 2016

Тем
0

Постов
10

Баллов
10
  • 04, Jan 2017
  • #34
В итоге перешли на UDP, контроль передачи данных отдали на откуп ПО
Так походу и обсуждается реализация именно этого ПО. Его реализация может стать в такой объем и количество багов, что ну его ... TCP и нет проблем. Тем боле сети все лучше и лучше.
 

test1c


Рег
25 Jul, 2010

Тем
1

Постов
23

Баллов
33
  • 19, Jan 2017
  • #35
udp хорош для малых проектов, для больших проектов лучше TCP.
Можно почитать на досуге, все расписано на примерах
 

cenitelas


Рег
11 May, 2015

Тем
0

Постов
3

Баллов
3
Тем
49554
Комментарии
57426
Опыт
552966

Интересно