Serial-over-Ethernet, (существует ли общепринятый стандарт?) Опции

[Doka]

что нужно:
иметь возможность пробрасывать UART в LAN с собственной ембеддед-коробочки и чтобы этот UART на хосте отображался как виртуальный последовательный порт (/dev/ttyX; COMx).
в первую очередь для Linux, во вторую - для M$ XP/Vista

начал ковырять инфопространство по поиску такого стандарта:
http://en.wikipedia.org/wiki/Serial_over_LAN - implemented as a payload type under the RMCP+ protocol in IPMI (аппаратная поддержка материнками???.. из серии KVM-over-LAN?)
http://sourceforge.net/projects/serialoverip/ - 2002г, линукс-то-линукс (не создаётся виртуального девайса)

огромное число коммерческих решений, использующих проприетарные(?) протоколы??
http://www.netburner.com/products/serial_to_ethernet.html
http://www.dcbnet.com/datasheet/ss1ds.html
http://www.industrialethernet.com/net232-dte.html
http://www.moxa.ru/group/listAll/14890/
- но это железки, а интересует лишь "стандартный" драйвер для хоста (виртуальный ком-порт) и описание инкапсуляции протокола для реализации на стороне ембеддед-девайса.

вот интересный продукт (Win & Lin) - http://www.virtualserialport.com/ :



но как это реализовывать на стороне ембеддед-девайса???




UPD: http://en.wikipedia.org/wiki/COM_port_redi...ource_solutions - вот тут список решений еще, кто-нибудь использовал что-нибудь из этого?..

[Рыжий Тигра]

Нужна помощь!

Есть Raspberry Pi 3, на нём pppd через GPRS-модем (скорость приёма-передачи - хорошо если 30-40 килобод), преобразователь USB-COM (подключен к некоему устройству на скорости 115200) и ser2net. На другом конце TCP-соединения - комп под Windows, на нём HW VSP (бесплатный однопортовый) и программа, которая умеет обмениваться пакетами с упомянутым устройством через COM-порт.
Проблема: как только размер отправляемого c компа пакета превышает три-четыре десятка байт, как в связке HWVSP-TCP-ser2net начинаются неприятности - пакет принимается на другом конце в два приёма: приходит начало пакета, а после паузы в три-четыре сотни миллисекунд - остальное. Устройство, натурально, расценивает этот таймаут как недопустимо большой и отбрасывает обе половинки пакета.
Опытным путём удалось установить, что допустимый интервал между байтами пакета - в пределах 20-30 миллисекунд, максимальный размер пакета - 255 байт, а программа не отправляет следующий пакет, пока не получит ответ на предыдущий либо пока не истечёт таймаут (а у программы он довольно длительный - десятки секунд).
Соответственно, вопрос: либо что можно сделать, чтобы пакеты не рвались при их передаче через TCP, либо какую софтинку применить на Windows-стороне, чтобы изображала из себя COM-порт и передавала данные UDP-пакетами?

[Tarbal]

Нужна помощь!

Есть Raspberry Pi 3, на нём pppd через GPRS-модем (скорость приёма-передачи - хорошо если 30-40 килобод), преобразователь USB-COM (подключен к некоему устройству на скорости 115200) и ser2net. На другом конце TCP-соединения - комп под Windows, на нём HW VSP (бесплатный однопортовый) и программа, которая умеет обмениваться пакетами с упомянутым устройством через COM-порт.
Проблема: как только размер отправляемого c компа пакета превышает три-четыре десятка байт, как в связке HWVSP-TCP-ser2net начинаются неприятности - пакет принимается на другом конце в два приёма: приходит начало пакета, а после паузы в три-четыре сотни миллисекунд - остальное. Устройство, натурально, расценивает этот таймаут как недопустимо большой и отбрасывает обе половинки пакета.
Опытным путём удалось установить, что допустимый интервал между байтами пакета - в пределах 20-30 миллисекунд, максимальный размер пакета - 255 байт, а программа не отправляет следующий пакет, пока не получит ответ на предыдущий либо пока не истечёт таймаут (а у программы он довольно длительный - десятки секунд).
Соответственно, вопрос: либо что можно сделать, чтобы пакеты не рвались при их передаче через TCP, либо какую софтинку применить на Windows-стороне, чтобы изображала из себя COM-порт и передавала данные UDP-пакетами?

Вы собрали из готовых кусков или что-то сами писали?
Условие, стимулирующее начало передачи пакета настолько неоднозначное и есть много взаимоисключающих критериев, что надо в каждом случае индивидуально отлаживать. Если сами писали код, то не помешает после записи сделать вызов int fsync(int fd);