Наши преимущества

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

Статус
Закрыто для дальнейших ответов.

vladgul

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

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

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

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

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

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

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

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

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

Ну как говорится - "хозяин барин", но я бы, например, меньше всего задумывался о транспорте, там и без меня все технологии уже давным-давно продуманы, и реализованы в множестве компонентов, а сосредоточился бы на на чем-нибудь более важном. Например, на архитектуре всей системы, с целью исключения самого слабого звена (плохого канала передачи данных).
 
  • Like
Реакции: Veda
Пока писал предидущий пост появилась эта информация )

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

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

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

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

Отсюда и был задан вопрос, с учетом запаса "прочности" какой все таки протокол лучше использовать, поскольку с UDP тоже не все так гладко.
 
Не совсем. Данные от датчиков собираются и анализируются автономной системой, а потом уже передаются на комп. Причем канал передачи
RS232 (COM). Эти данные собираются программой драйвером и уже потом
идет обмен (о котором и идет речь в этой теме) с программой сервером.

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

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

Добавлено через 5 минут
Для c++ есть библиотека Google Libjingle в которой реализован собственный надежный протокол PseudoTCP на основе UDP.
 
Последнее редактирование модератором:
Если у вас 80% потерь пакетов в сети при использовании ТСР то при переходе на UDP их 80% и останется. От этого не изменится абсолютно ничего. А вот свой "ведлсипед" для организации надёжного обмена обойдётся достаточно дорого.
Если у вас проблемы возникают изза DDoS тогда может поработать в направлении защиты а не прыгать между протоколами? Атаковать UDP тоже можно достаточно неплохо :)
 
Рассмотрите для решения описываемой проблемы ZeroMQ.
Или возьмите на вооружение MQTT протокол.

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

MQTT - протокол, ориентирован на быструю и надежную доставку упакованных в бинарный конверт пакетов.
Пришел из интернета-для-железяк Как увидеть ссылки? | How to see hidden links?.
Нужен сервер, реализующий протокол.
Свободных - в достаточном количестве.
Как увидеть ссылки? | How to see hidden links?
 
Вообще во избежании потерь пакетов на ненадежном участке(линия больше 100 метров и д.р.) уменьшают размер пакета(MTU) с 1500 до 576 байт. Скорость просаживается, но все работает.
 
Статус
Закрыто для дальнейших ответов.
Верх