@RadioHam433

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

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

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

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

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

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

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

Вернуться к обсуждению:
Дублирование пакетов UPD лишнее? Программирование

0