Cómo saber cuando NC haya terminado de transferir un archivo

¿Hay alguna manera de saber cuándo netcat termina de transferir un archivo entre máquinas?

Comandos actuales:

Máquina # 2: nc -lp 5555 > test.txt

Máquina # 1: nc MachineIP Port < test.txt

La transferencia ocurre, pero no hay indicación visual de que se haya completado.

Primero algunos antecedentes

Existen diferentes versiones de nc, como puede encontrar en nc (1) - página de manual de Linux o nc (1) BSD General Commands Manual, la conexión debe cerrarse justo después de la transferencia. Hay un ejemplo dado en ambos sitios vinculados:

Comience usando nc para escuchar en un puerto específico, con la salida capturada en un archivo:

$ nc -l 1234 > filename.out

Con una segunda máquina, conéctese al proceso nc de escucha y alimente el archivo que se va a transferir:

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

Después de que el archivo se haya transferido, la conexión se cerrará automáticamente.

Su netcatno se cierra la conexión después de la transferencia, por lo que es diferente de la (s) descritos anteriormente. Se comporta como el mío, Netcat 1.10 en Debian Jessie. Este comportamiento está documentado en /usr/share/doc/netcat-traditional/README.gz(en mi máquina), la carga es mía:

En el uso más simple, "nc host port" crea una conexión TCP al puerto dado en el host de destino dado. Su entrada estándar se envía al host, y todo lo que vuelve a través de la conexión se envía a su salida estándar. Esto continúa indefinidamente, hasta que el lado de la red de la conexión se apaga. Tenga en cuenta que este comportamiento es diferente de la mayoría de las otras aplicaciones que cierran todo y salen después de un final de archivo en la entrada estándar.

Aquí está el razonamiento detrás de este comportamiento:

Tal vez se pregunte "¿por qué no usar telnet para conectarse a puertos arbitrarios?" Pregunta válida, y aquí hay algunas razones. Telnet tiene el problema de "EOF de entrada estándar", por lo que uno debe introducir demoras calculadas en los scripts de conducción para permitir que finalice la salida de la red. Esta es la razón principal por la que netcat permanece en funcionamiento hasta que se cierra el lado de la red .

Wikipedia tiene una lista de diferentes implementaciones . Sin embargo, no puedo nombrar diferencias. Tal vez alguien más puede?

Ahora soluciones

1

Puede decir ncque salga después de que se haya leído el archivo. Esta opción es útil:

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

Si usa este comando en el extremo de envío:

nc -q 0 MachineIP Port < test.txt

ncse cerrará 0 segundos después de leer EOF, justo después de que el archivo haya finalizado. Luego saldrá y también lo hará el extremo receptor nc.

Si te preguntas qué sucede si los paquetes no se cruzan, aquí hay un comentario de Juraj.

Cuando no se encuentran todos los paquetes, el sistema lo detectará y los retransmitirá sin que la aplicación lo note (o si no es posible, la aplicación recibirá un error de tiempo de espera). La entrega confiable es el propósito del protocolo TCP proporcionado por el núcleo del sistema operativo, que ncutiliza. Puede solicitar el protocolo UDP que no hace esto, nc -upero no es el caso.

2

Hay un ejemplo original en lo anterior README.gz, que se basa en el -wtiempo de espera y no requiere la -qopción de estar presente en su implementación.

Netcat puede usarse como un simple agente de transferencia de datos, y realmente no importa qué extremo es el oyente y qué extremo es el cliente: la entrada en un lado llega al otro lado como salida. Es útil iniciar el oyente en el lado receptor sin tiempo de espera especificado, y luego darle al lado emisor un pequeño tiempo de espera. De esta forma, el oyente permanece escuchando hasta que lo contacte, y después de que los datos dejen de fluir, el cliente se desconectará, se cerrará y se llevará al oyente. A menos que la red que interviene esté llena de problemas, esto debería ser completamente confiable y siempre puede aumentar el tiempo de espera. Un ejemplo típico de algo "rsh" se usa a menudo para: por un lado,

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

y luego al otro lado

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

transferirá el contenido de un directorio de una máquina a otra, sin tener que preocuparse por archivos .rhosts, cuentas de usuario o configuraciones inetd en ninguno de los extremos.