@RadioHam433

Привествую всех! Собственно у меня возник немного казусный вопрос на счёт защиты от потери пакетов UDP. Конечно 1 что просится это дублирование с подтверждение, то есть остановкой дублирования как я делал до этого но там имеет место быть прямая линия/эфир задержка чисто физическая более лимита в 100мс сигнал просто не передать там это всё идеально работает. А вот как быть с UDP я сделал всё же дублирование то есть пакеты в сессии отправляются несколько раз подряд мне кажется можно уменьшить задержку в случае потери чем ждать подтверждения по истечению времени дублировать тем более тут задержки не нормированы уже. Но дублирование увеличивает трафик понятно дело но в принципе он совсем небольшой.

Какие варианты есть? Сразу скажу от TCP я отказался, мне нужна простота/надёжность быстродействие как в на физическом канале отправил не каких тормозов и зависаний при отправке. В этом плане UDP полностью меня устраивает пакеты отправляются в никуда без вопросов.

0

@Shamil1

Основная черта UDP - отсутствие подтверждения.

0

@vantfiles

Именно так, но добавить подтверждения и перезапрос по таймауту не составляет труда.

Впрочем, я не представляю себе, где и как могут теряться пакеты. У меня сервер по UDP последние 10 лет работает без каких-то там потерь.

0

@RadioHam433

Но я пошёл по алгоритму передачи данных в прямом канале, что дублировать пакет до получения подтверждения получается на порядки лучше. Но в прямом канале задержка = расстоянию там всё чётко когда данные идут между точками. Если нет ответа значит уже потерялось ибо 1000мс не может идти 1км но вот по любому! А когда пакет проходит через 100500 узлов то задержка уже не нормируется чисто по определению. Просто запустив пинг каждый раз время разное и притом иногда возникают задержки во много раз превышающие средние.
А тут может быть и 10мс скажем и 1000мс! Может быть и 1000мс нормальная задержка и при таймауте 100мс получится 10 перезапросов за 1000мс и полностью загруженный канал дублями без потерь. А где в локальной сети и 10мс это можно считать ошибкой вот собственно и приехали и даже ждать 100мс меньше чем недопустимо. Потому я пока выбрал отправлять до подтверждения так же с определённым интервалом и по превышению времени считать ошибкой канала.
Возможно я не прав но есть задача именно максимизировать быстродействие системы уменьшить задержку. Конечно я имел ввиду это не передачи больших объёмов данных а только для данных к которые надо как можно быстрее доставить.

0

Алексей1153

RadioHam433, как насчёт варианта всё же использовать TCP, но передавать сразу по 10 пакетов?

0

@RadioHam433

Неееет! TCP глючная штука! Мне нужен просто надёжный вариант который не даёт ошибок и не зависает. С TCP были проблемы что пытаясь сделать отправку в никуда функция зависает на некоторое время тормозя другие отправки короче это дно!

0

Алексей1153

RadioHam433, странно, у меня ничего не зависает. И у кучи народа на планете тоже

Добавлено через 3 минуты
видимо, как-то неправильно работаешь.

UDP - это хороший вариант для потоковых данных (для них не нужна обратная связь): видео, аудио, телеметрия

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

Добавлено через 1 минуту
чтобы "функция не зависала" нужно использовать асинхронный обмен. Или работать в другом потоке (кстати, какие платформа и язык - не указано в теме)

1

@vantfiles

А может быть websocket ?

0

@RadioHam433

Так для ЦСУ основной трафик это телеметрия, система управления. Синхронность данных/состояния актуальность отображения с реальным состоянием, система управления минимальная реакция.

Да это асинхронный обмен понятно дело. 1-е у меня не было особо времени надо было быстро систему сделать. 2-е зависание не намертво а на какое то время пока не данные не доставятся или время не выйдет. У меня система асинхронная вообще исходно куча потоков так сказать реалтаймовая без зависаний, для всех ненормированных операций свой поток. Любую инструкцию можно запустить асинхронно. Было на TCP толком не разобрался с ним честно. Но работы UDP мне показалась на порядок надёжнее, стабильнее максимальна приближена к тому с чем я работал в прямо канале, там чисто по определению не может быть TCP все подтверждения чисто на программно уровне.

Язык basic.net я использую мелкософтную студию, там собственно язык не важен всё равно среда исполнительная одна.

Дело в том что система универсальная не имеет ничего прописанного в коде, инструкции лежат в файле и могут менять в реальном времени. Но а так же много вариантов протоколов связи которые рассчитаны на потерю пакетов в одну сторону, то есть у меня исходно система управления имеет возможность работать в одностороннем режиме потому надёжность идеальная. Как я и сказал протокол не подразумевает ожидания подтверждения для отправки данных, идёт дублирование пока не будет получено подтверждение, сдед данные будет отправляться так же и если подтверждение будет получено после данные уже будут доставлены. У данных есть время жизни, например данные телеметрии передаются при обновлении и периодически у них время жизни до обновления по любому. Есть то что без лимита живёт, оно может быть доставлено скажем при появлении связи, но или доставлено сразу а подтверждение получить спустя сутки, всё это время будут попытки доставить когда получит подтверждение попытки прекратятся. Счётчик сессии LONG там хватит на месяцы что бы порядок сохранить при интенсивном обмене.

Я пошёл по пути прямого канала когда в любом направлении может возникнуть потеря пакетов (простая помеха) но система не теряет работоспособности скажем как если бы Wi-Fi или сотовую заглушить приём мобильному абоненту то на базу не получится доставить данные то тут такой проблемы нет, система может долго работать в одну сторону, но или база не будет слышать мобильного абонента то не получить данные мобильному абоненту который слышит базу.

Свой велосипед разработанный для конкретных задач на порядок круче чем какой то.

Я вообще начинал с низкоскоростных каналов связи большой дальности системы управления и телеметрии, потому там выход был только один для уменьшения задержек это проще отправить несколько пакетов как при слабом сигнале проходит пойти случайный пакет скажем 0|5|3|1|0|5|5|3|1| но имеется ввиду 1 пакет который прошёл, при нормальном сильном сигнале уже всегда 0 если нет помех. Вот собственно и так сложилось.
Все эти широкие каналы на гигах для меня как красные вороны на фоне что ПДУ брелок работает на километры многие километры.

0

@locm

Разве нет события отключения клиента от сервера или сервера от клиента? Если связь разорвали, то зачем отсылать данные? Тогда тормозить не будет. Единственная причина торможения - превышение пропускной способности канала связи, но если TCP притормаживает адаптируясь под полосу канала, на UDP будет значительная потеря пакетов.

0

@RadioHam433

Всё есть!
Я так сказал! Оно не должно тормозить в любом случае дольше чем на время передачи пакета за пределы физического устройства, после того как данные покинули физическое устройство всё должно быть готово к отправке след пакета в любом случае! Всё остальное не мои проблемы. Нет никакой потери пакетов всё идеально! UDP не тормозит всё зашибись на том можно закрывать тему. Лучшего варианта нет как всегда я в этом убедился всем спасибо!

0