Как узнать, когда NC завершил передачу файла

Есть ли способ узнать, когда netcat завершил передачу файла между компьютерами?

Текущие команды:

Машина № 2: nc -lp 5555 > test.txt

Машина № 1: nc MachineIP Port < test.txt

Передача происходит, но нет визуальной индикации того, что она завершена.

Сначала немного предыстории

Существуют разные версии nc, как вы можете найти на странице руководства nc (1) - Linux или в руководстве по основным командам BSD nc (1), соединение должно быть закрыто сразу после передачи. На обоих связанных сайтах приведен пример:

Начните с использования nc для прослушивания определенного порта, с выводом, записанным в файл:

$ nc -l 1234 > filename.out

Используя второй компьютер, подключитесь к процессу прослушивания nc, передав ему файл, который необходимо передать:

$ nc host.example.com 1234 < filename.in

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

Вы netcatне закрываете соединение после передачи, поэтому оно отличается от описанного выше. Он ведет себя как мой, Netcat 1.10 на Debian Jessie. Это поведение задокументировано в /usr/share/doc/netcat-traditional/README.gz(на моей машине), болтовня моя:

В простейшем случае «nc host port» создает TCP-соединение с указанным портом на указанном целевом хосте. Затем ваш стандартный ввод отправляется на хост, а все, что возвращается через соединение, отправляется на ваш стандартный вывод. Это продолжается до бесконечности, пока сетевая сторона соединения не отключится. Обратите внимание, что это поведение отличается от большинства других приложений, которые выключают все и выходят после окончания файла на стандартном вводе.

Вот причины этого поведения:

Вы можете спросить "почему бы просто не использовать telnet для подключения к произвольным портам?" Правильный вопрос, и вот несколько причин. В Telnet существует проблема «стандартного ввода EOF», поэтому необходимо ввести расчетные задержки в сценариях управления, чтобы завершить вывод по сети. Это основная причина, по которой netcat продолжает работать до тех пор, пока сторона сети не закроется.

В Википедии есть множество различных реализаций . Я не могу назвать различия, хотя. Может кто еще может?

Теперь решения

1

Вы можете сказать, ncчтобы выйти после того, как файл был прочитан. Эта опция полезна:

-q seconds   after EOF on stdin, wait the specified number  of  seconds
             and then quit. If seconds is negative, wait forever.

Если вы используете эту команду на конце отправки:

nc -q 0 MachineIP Port < test.txt

ncвыйдет через 0 секунд после чтения EOF, то есть сразу после окончания файла. Затем он выйдет и так же получит конец nc.

Если вам интересно, что происходит, если пакеты не пересекаются, вот комментарий от Juraj.

Когда все пакеты не попадают, система обнаружит это и повторно передаст их без уведомления приложения (или, если это невозможно, приложение получит ошибку тайм-аута). Надежная доставка является целью протокола TCP, предоставляемого ядром ОС, которое ncиспользует. Вы можете запросить протокол UDP, который не делает этого, используя, nc -uно это не так.

2

В вышеупомянутом есть оригинальный пример README.gz, который основан на -wтайм-ауте и не требует наличия -qопции в вашей реализации.

Netcat можно использовать как простой агент передачи данных, и на самом деле не имеет значения, какой конец является слушателем, а какой - клиентом - вход с одной стороны поступает на другую сторону как выход. Полезно запустить прослушиватель на принимающей стороне без указания времени ожидания, а затем дать отправляющей стороне небольшой тайм-аут. Таким образом, слушатель продолжает слушать, пока вы не свяжетесь с ним, и после того, как данные перестанут течь, клиент отключится и завершит работу с ним. Если вмешивающаяся сеть не сопряжена с проблемами, это должно быть абсолютно надежно, и вы всегда можете увеличить время ожидания. Типичный пример чего-то, что «rsh» часто используется для: с одной стороны,

nc -l -p 1234 | uncompress -c | tar xvfp -

а потом на другой стороне

tar cfp - /some/dir | compress -c | nc -w 3 othermachine 1234

переместит содержимое каталога с одного компьютера на другой, не беспокоясь о файлах .rhosts, учетных записях пользователей или конфигурациях inetd с обеих сторон.