Файловый сервер socat TCP
Я пытаюсь настроить простой файловый сервер socat, использующий TCP для отправки небольших файлов (~100 КБ).
Вот однострочные серверы и клиент для одного файла:
Сервер: socat -u -d -d OPEN:file.dat TCP-LISTEN:<port>,reuseaddr,fork
Клиент: socat -u -d -d TCP:<server>:<port> OPEN:file.dat,creat
Первая передача данных всегда работает, но следующие не всегда работают. Большая часть следующей передачи создает пустой файл на стороне клиента. Проблема сохраняется с несколькими клиентами, передающими один раз, и я очень убежден, что данные не передаются при возникновении ошибки, но значения в журнале и возвращаемые значения не указывают на какие-либо ошибки, только более короткий цикл данных.
Я попробовал почти все варианты, упомянутые здесь: http://www.dest-unreach.org/socat/doc/socat.html
Единственный способ заставить его работать несколько раз подряд - это удалить опцию fork из прослушивателя сервера и обернуть всю строку commande в цикл bash, но, конечно, он не работает для нескольких клиентов.
Я пробовал с Ubuntu, Fedora, Redhat и FreeBSD.
Я что-то упустил или это ошибка?
3 ответа
У меня была та же проблема, и мне потребовались часы, чтобы понять, что я делаю неправильно. Я все еще не знаю, но я знаю, по крайней мере, как заставить это работать. Я использовал:
socat -u FILE:/tmp/test.txt TCP-LISTEN:5778,reuseaddr,fork
И это сработало, как и ожидалось, когда я переключился на:
socat TCP-LISTEN:5778,reuseaddr,fork FILE:/tmp/test.txt
Я не уверен, что на самом деле меняется, но отбрасывая -u
Отметьте и поменяйте местами порядок адресов, откроется сокет для нескольких вызовов клиентов. Я наткнулся на него, пытаясь продублировать известный рабочий пример сервера.
Также мой клиент был просто socat -u TCP:localhost:5778 STDOUT
, Работает без -u
также.
Мужчина мужчина
$ man socat | grep -m1 '\-u' -A3
-u Uses unidirectional mode. The first address is only used for
reading, and the second address is only used for writing (exam-
ple).
даже просто помогите
$ socat -h | grep -m1 '\-u '
...
Это связано с тем, что на сервере имеется один источник файлов и несколько приемников файлов (разветвленные соединения TCP). Первый клиент потребляет весь файл, оставляя позицию файла в EOF (конец файла). Любым последующим TCP-клиентам нечего читать, поскольку все они используют один и тот же источник файлов.
Это скорее аспект дизайна socat, чем ошибка. Я не знаю, как новые соединения могут сбросить позицию поиска в исходном файле.