Как решить проблему потерь пакетов при пробросе порта на tcp server?

Question

[AlexSer]

Написал простой TCP сервер для приема данных на порт(windows).
Пробрасываю com через nc на порт сервера.
Сторона сервера, чтение сокета:

void TcpServer::ReadData()
{
          QByteArray byte=socket->readAll();
          terminal->append(byte);
}

На клиенте линукс проброс портов:
nc IP port < /dev/ttyACM0>/dev/ttyACM0
При передаче с устройства теряются пакеты, что может влиять?

Answer 1

[res2001]

что может влиять?

Много факторов: медленная/высокая скорость на одном из портов и/или не достаточная длина буфера, большая загрузка ЦП во время работы (причем он может быть загружен любой не связанной задачей), плохое качество связи по сети, что приводит к повторной передаче и тормозит текущую передачу, что приводит к переполнению буферов и т.п.
Учитывая, что в TCP данные не могут теряться, значит они теряются либо по дороге в nc, либо внутри nc.
Если в nc есть возможность поиграть с размерами буферов - поэкспериментируйте с ними. Но часто универсальные решения не являются оптимальными для конкретной задачи.

Comments

[AlexSer]

А можно напрямую через терминал подключиться к ком порту и посмотреть как он передает?
Если да то какой командой? Просто может быть проблема и в драйвере устройства.

[res2001]

AlexSer, Используйте любую программу, которая умеет работать с последовательными портами, например minicom, или что-то еще, их много.

Можно даже так: cat </dev/ttyACM0
Но, конечно, порт в системе должен быть правильно сконфигурирован. Программы общего назначения сами не умеют правильно конфигурировать порт, поэтому вы должны об этом позаботится.
Тот же minicom сам может сконфигурировать порт через свои настройки/опции.

[AlexSer]

res2001, да все насстройки порта у меня есть спс

[AlexSer]

res2001, оказалась проблема в драйвере! Теперь вопрос можно ли узнать какой драйвер стоит
затем найти и переустановить на более новую версию или старую?
Подключил устройство на пряму к виндовс все нормально передает, без потерь пакетов. Но мне надо решить именно на линуксе!

[res2001]

AlexSer, В линуксе все драйвера в ядре. Либо встроены, либо в виде подгружаемых модулей.
На сколько я знаю, драйвер для ttyACM встроен в ядро, так же как и для ttyUSB и ttyS.
Так что смена драйвера - это только смена ядра.
Что за проблема в драйвере?

[AlexSer]

res2001, пакеты идут не попорядку! Вставляет пустые строки, теряет символы.
Данные идут не корректно, подсоеденил утсройство на виндовс, получил данные корректные!
Может есть "полные" настройки? Установил minicom вроде поставил такие же настройки как в утсройстве, но ничего не изменилось.

[res2001]

AlexSer, Какие полные настройки? Настройки обычные для последовательного порта: скорость, количество бит данных, количество стоповых бит, проверка четности, контроль потока.

пакеты идут не попорядку

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

Что-то я сомневаюсь, что в ttyACM есть известные не исправленные баги. Драйвер далеко не новый, существует в ядре давно. https://www.kernel.org/doc/html/latest/usb/acm.html

[AlexSer]

res2001, Вот пример логов

//пакеты пришли без начала сообщения нет <Begin Chksum>
TCP\IP сервер успешно запущен!

//последняя передача правильная
<!--:Begin:Chksum:1:-->
<!--:Begin:Msg:8:0:-->
<sample>
<ver>1.1</ver>
<instrinfo>
<p><n>PRDI</n><v>BM800</v></p>
<p><x42c;</v></p>
<p><n>ASPM</n><v>OT</v></p>
<p><n>ASPS</n><v>1</v></p>
<p><n>SORC</n><v>0</v></p>
<p><n>BLMD</n><v>0</v></p>
n><v>2008-039</v></p>
<p><n>RDPN</n><v>18</v></p>
<p><n>RDED</n><v>2023-08-03</v></p>
<p><n>RLLI</n><v>2110-053</v></p>
<p><<p><n>RPDF</n><v>27</v></p>
<p><n>MBTE</n><v>26.8</v></p>
<p><n>MCVO</n><v>+0.0</v></p>
<p><n>WDDM</n><v>0</v></p>
<p><n>WDD/p>
<p><n>WDLH</n><v>400</v></p>
<p><n>WDCL</n><v>134</v></p>
<p><n>WDCH</n><v>177</v></p>
<p><n>WLGL</n><v>160</v></p>
<p><n>XLT</n></p>
<p><n>EOMD</n></p>
<p><n>EODL</n></p>
<p><n>EODH</n></p>
<p><n>EOAC</n></p>
<p><n>EOWC</n></p>
<p><n>XEIT</n></p>
<p><n>EASS</n></p>
<p><n>CAPL</n></p>
<p><n>CLVL</n></p>
<p><n>CEXP</n></p>
<p><n>CEXT</n></p>
<p><n>EXCL</n></p>
<h>5.50</h></p>
<p><n>MCV</n><v>77.8</v</p>
<p><n>MCHC</n><v>35.4</v><l>31.0</l><h>38.0</h></p>
<p><n>RDWR</n><v>11.8</v><l>11.0</l><h>16.0</h></p>
<p><n>RDWA</n><v>48.1</v><l>30.0</l><h>150.0</h></p>
<p><n>PLT</n><v>204</v><l>100</l><h>400</h></p>
<p><n>MPV</n><v>9.8</v><l>8.0</l><h>11.0<>24.1</v><l>0.1</l><h>99.9</h></p>
<p><n>HGB</n><v>13.9</v><l>11.5</l><h>16.5</h></p>
<p><n>WBC</n><v>5.3</v><l>3.5</l><h>10.0</h></p>
<p><n>LA</n><v>2.2</v><l>0.5</l><h>5.0</h></p>
<p><n>MA</n><v>0.5</v><l>0.1</l><h>1.5</h></p>
<p><n>GA</n><v>2.6</v>><n>GR</n><v>48.9</v><l>35.0</l><h>80.0</h></p>
</smpresults>
<tparams>
<p><n>RCT</n><v>15774</v></p>
<p><n>WCT</n><v>10771<n><v>4238</v></p>
</tparams>
</sample>
<!--:End:Msg:8:0:-->
<!--:End:Chksum:1:6:148:-->

Каждая отправка должна начинаться и заканчиваться на
Даже прямой прием через cat выводит почти тоже самое.
Посмотрел ту ссылку которую Вы дали, но там насчет буфера драйвера ничего не нашел.

[AlexSer]

Пример неправильной отправки
Нет ни начала ни конца передачи, сразу центральная часть. Потом может между сообщениями может вставить начало или конец.

>FIWV</n><v>2.9.0</v></p>
<p><n>SNO</n><v>22444</v></p>
<p><n>BRND</n><v>M</v></p>
<p><n>IAPL</n><v>H</v></p>
<p><n>IID</n>
Not full data!
><v>2022-05-12T09:14:31</v></p>
<p><n>OPID</n></p>
<p><n>APNU</n><v>1</v></p>
<p><n>APNA</n><v>&#x41a;&#x420;&#x41e;&#x412;&#<p><n>BLNK</n><v>0</v></p>
<p><n>STYP</n><v>0</v></p>
<p><n>RGED</n></p>
<p><n>RGEL</n></p>
<p><n>RGEC</n></p>
<p><n>RDLI</n>RLPN</n><v>42</v></p>
<p><n>RLED</n><v>2024-10-12</v></p>
<p><n>RCLI</n></p>
<p><n>RCPN</n></p>
<p><n>RCED</n></p>

[res2001]

AlexSer, Что за устройство у вас там висит?
Поток данных интенсивный? Подобная портянка за сколько времени накапливается?

В линуксе по умолчанию все данные с tty прогоняются через фильтры, по моему, это называется line discipline, там идет анализ входных данных на команды терминала (линукс по умолчанию считает, что к порту подключен терминал). Команды применяются и удаляются из данных.
Вам надо получать сырые данные (raw) и надо все эти фильтры отключить.
Сделать это можно с помощью утилиты stty. Смотрите man stty
Команда будет выглядеть как-то так:
stty -F /dev/ttyACM0 raw
Тут же можно задать и все остальные параметры порта.
Есть еще утилита setserial, там то же можно выставлять какие-то параметры.
Обе утилиты, возможно, надо будет дополнительно установить.

Возможно с помощью этих утилит можно выставить и размер буфера приема. Размер буфера точно можно регулировать программно с помощью системных вызовов. Но не уверен, можно ли это сделать с помощью утилит типа stty. Возможно есть соответствующая настройка в том же minicom.

[res2001]

AlexSer,

Пример неправильной отправки

Устройство с той стороны очень часто не может определить слушает ли кто-то порт.
Оно просто шлет данные в порт, не заботясь о том, есть ли кто-то с той стороны или нет.
Если у вас как раз такой вариант, то при подключении вы запросто можете попасть на середину отправляемых данных.
Да, в UART есть управляющие сигналы, с помощью, которых это можно делать. Но часто эти сигналы просто не используются. Для работы последовательного порта RS232 достаточно двух трех проводов, на сколько я помню (RX, TX, GND). RS485 вообще обходится двумя. Все остальное - дополнительные опции, которых может не быть физически.

[AlexSer]

res2001,
да я решил проблему с чтением данных с serial порта. Нашел аналогичную проблему
Ссылка
Скопировал код на прием с ком порта

#!/bin/sh
insmod usbserial
insmod ftdi_sio
insmod cdc-acm

while [ true ]
do

stty -F /dev/ttyACM0 cs8 9600 ignbrk -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke noflsh -ixon -crtscts raw
	while read LINE
	do
	//echo $LINE
       //сделал переброс
   <b>   echo $LINE |  nc tcp port </b>
	 		
	done < /dev/ttyACM0
/bin/sleep 3
done

но таким способом тоже потеря пакетов, теперь кажется на стороне TCP сервера!
Посмотрел nc --help там насчет буфера отправителя параметров не нашел.

[AlexSer]

res2001, насчет сигналов устройства ENQ, ACK, NAK и EOT даже их если включаю в самом устройстве,
он не работает, перекидывает все данные сразу без полученных сигналов ACK от получателя. На них толку нет. Посмотрю QtTcpServer может там есть функции по управлению буффером сокета.

[res2001]

AlexSer,

насчет сигналов устройства

Не знаю, что это за сигналы. В UART таких нет :)

теперь кажется на стороне TCP сервера

Протокол TCP обеспечивает доставку данных. Это значит, что если данные попали в сокет, то они по любому будут доставлены (или будет разорвано соединение по таймауту). Так что на стороне сервера вы по любому получите все данные, которые отправил nc. Даже если ваш сервер криво написан и тормозит.
Но вот nc уже может отправлять далеко не все данные.
Вообще скорость порта 9600 маленькая, нагрузку на сеть подобный поток вызывает не большую, легко справится даже 100 Мбит сеть.
Попробуйте со стороны сервера так же запустить nc (вместо вашего сервера), получать данные из сети и писать их в файл. Посмотрите, что будет в файле. Будет ли пропадание данных и т.п. Если в таком варианте с данными будет все нормально - то ваш сервер не справляется.

[AlexSer]

res2001, Еще один вопрос:
У меня еще 2 точно таких же устройств, подключил через serial usb как для них установить этот драйвер ACM0? Что где прописать?

[res2001]

AlexSer, Когда подключите дополнительные устройства у вас должны автоматически появиться дополнительные файлы устройств: /dev/ttyACM1, /dev/ttyACM2, ...

[AlexSer]

res2001, такого точно нет. Только ACM0 видит

[res2001]

AlexSer, Дополнительные устройства вы подключаете дополнительно к первому или вместо него?

[AlexSer]

res2001, дополнительно

[res2001]

AlexSer, Надо смотреть системные логи, там должны быть сообщения о подключении новых устройств и ошибки из-за которых не появляются новые файлы устройств. Устройства могут быть заблокированы, например, правилами udev.
Дополнительные устройства идентичны первому? Для других типов устройств могут использоваться файлы /dev/ttyUSB

И хорошо бы проверить, что дополнительные устройства вообще работают.