#sockets #serial-port #udp #crc
#сокеты #последовательный порт #udp #crc
Вопрос:
У меня есть (очень) старое программное обеспечение, написанное на C, которое использовалось для двух устройств, которые обмениваются данными по последовательному кабелю (RS232) — как для отправки, так и для получения сообщений.
Теперь старые устройства должны быть заменены новыми современными, у которых нет последовательных портов, а только Ethernet.
Следовательно, теперь требуется преобразовать старую последовательную связь в UDP-связь (на данный момент выбор C ).
Итак, у меня есть несколько вопросов об этом «преобразовании»:
1) Предположим, что есть два одноранговых узла A и B. Должен ли я реализовать сервер и клиент для каждого однорангового узла, т.Е.: ServerA ClientA (для устройства A) и ServerB ClientB (для устройства B)? Или есть какой-то другой / другой подход ?…
2) В старой последовательной связи был некоторый CRC, вероятно, для обеспечения некоторой надежности. Необходимо ли реализовывать CRC (в моих пользовательских сообщениях) также для связи UDP или нет?
Заранее спасибо за ваше время и терпение.
Ответ №1:
1) UDP — это протокол без установления соединения, поэтому здесь нет жестких ролей клиента и сервера. У вас просто есть некоторый код, который обрабатывает прием, и некоторый код, который облегчает отправку.
2) Вам не нужен CRC для UDP. Во-первых, в каждом кадре Ethernet есть FCS (CRC32). Затем в IP-пакетах есть контрольная сумма заголовка. В конце концов, контрольная сумма уже включена в дейтаграмму UPD!
Пожалуйста, также рассмотрите следующие вещи:
- В повседневной жизни COM-порты давно исчезли из физического мира, но они все еще с нами в виртуальной форме (даже телефоны Android имеют COM-порты). Существует множество решений для выполнения COM через USB / TCP / что угодно. Некоторые из них являются приложениями для ПК, некоторые из них реализованы аппаратно (см. COM Arduino через USB),
- Когда UDP-дейтаграмма не проходит проверку контрольной суммы, она отбрасывается (обычно) молча. Таким образом, в UDP у вас нет встроенных возможностей для различения «ничего не было получено» и «мы получили что-то, но это недействительно». Проверьте UDP-Lite, если вы хотите справиться с этими ситуациями на уровне приложения (я полагаю, это должно упростить процесс переноса).
- По умолчанию для передачи данных используется протокол TCP, поскольку он обеспечивает надежную доставку. UDP рекомендуется для пользователей, которые заботятся о режиме реального времени, и для тех, кто может допустить некоторую потерю данных. Или для тех, кто заботится о ресурсах.
- Выберите TCP, если вы собираетесь отправлять большой объем данных или быть готовым к перегрузке пакетов на портах. Выберите TCP, если вы планируете в будущем перейти на беспроводную связь или быть готовым к периодической значительной потере пакетов.
- Если ваши устройства действительно крошечные или заполнены другим материалом, можно работать непосредственно на уровне 2 (Ethernet).
Комментарии:
1. Это именно те ответы, которые мне были нужны. Также спасибо за дополнительные соображения, действительно ценю это. У меня было некоторое представление о связи UDP, но я чувствовал необходимость быть уверенным на 100%. Лучше спросить, чем сожалеть 🙂 На рассматриваемых устройствах работает встроенный Linux в локальной сети, поэтому мы выбрали UDP (я думаю, у TCP гораздо больше накладных расходов …). С уважением, Стэнли Г.