Comment savoir quand NC a fini de transférer un fichier

Existe-t-il un moyen de savoir quand netcat a terminé le transfert d'un fichier entre des machines?

Commandes actuelles:

Machine n ° 2: nc -lp 5555 > test.txt

Machine n ° 1: nc MachineIP Port < test.txt

Le transfert a lieu, mais rien n'indique visuellement qu'il s'est terminé.

Tout d'abord quelques antécédents

Il existe différentes versions de nc, comme vous pouvez le trouver sur la page de manuel nc (1) - Linux ou nc (1) BSD General Commands Manual, la connexion doit être coupée juste après le transfert. Il y a un exemple donné sur les deux sites liés:

Commencez par utiliser nc pour écouter sur un port spécifique, avec la sortie capturée dans un fichier:

$ nc -l 1234 > filename.out

À l'aide d'une deuxième machine, connectez-vous au processus d'écoute nc, en lui fournissant le fichier à transférer:

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

Une fois le fichier transféré, la connexion se ferme automatiquement.

Votre netcatne ferme pas la connexion après le transfert, elle est donc différente de celle décrite ci-dessus. Il se comporte comme le mien, Netcat 1.10 sur Debian Jessie. Ce comportement est documenté dans /usr/share/doc/netcat-traditional/README.gz(sur ma machine), le gras est le mien:

Dans l'utilisation la plus simple, "nc host port" crée une connexion TCP au port donné sur l'hôte cible donné. Votre entrée standard est ensuite envoyée à l'hôte, et tout ce qui revient via la connexion est envoyé à votre sortie standard. Cela se poursuit indéfiniment, jusqu'à ce que le côté réseau de la connexion s'arrête. Notez que ce comportement est différent de la plupart des autres applications qui arrêtent tout et se terminent après une fin de fichier sur l'entrée standard.

Voici le raisonnement derrière ce comportement:

Vous demandez peut-être "pourquoi ne pas simplement utiliser telnet pour se connecter à des ports arbitraires?" Question valide, et voici quelques raisons. Telnet a le problème "EOF d'entrée standard", donc il faut introduire des délais calculés dans les scripts de pilotage pour permettre la sortie du réseau. C'est la principale raison pour laquelle netcat continue de fonctionner jusqu'à la fermeture du côté réseau .

Wikipédia a un certain nombre d'implémentations . Je ne peux cependant pas nommer les différences. Peut-être que quelqu'un d'autre peut le faire?

Maintenant, des solutions

1

Vous pouvez dire ncde quitter une fois le fichier lu. Cette option est utile:

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

Si vous utilisez cette commande du côté de l'envoi:

nc -q 0 MachineIP Port < test.txt

ncquittera 0 seconde après avoir lu EOF, c'est-à-dire juste après la fin du fichier. Il sortira ensuite, de même que l'extrémité de réception nc.

Si vous vous demandez ce qui se passe si les paquets ne passent pas, voici un commentaire de Juraj.

Lorsque tous les paquets ne sont pas rencontrés, le système le détectera et les retransmettra sans que l'application ne s'en rende compte (ou si cela n'est pas possible, l'application obtiendra une erreur de temporisation). La livraison fiable est l'objectif du protocole TCP fourni par le noyau du système d'exploitation, qui ncutilise. Vous pouvez demander le protocole UDP qui ne fait pas cela, en utilisant nc -umais ce n'est pas le cas.

2

Il y a un exemple original dans ce qui précède README.gz, qui est basé sur le -wdélai d'expiration et ne nécessite pas l' -qoption d'être présent dans votre implémentation.

Netcat peut être utilisé comme un simple agent de transfert de données, et peu importe quelle extrémité est l'écouteur et quelle extrémité est le client - l'entrée d'un côté arrive de l'autre côté en sortie. Il est utile de démarrer l'écouteur du côté de la réception sans délai d'expiration spécifié, puis de donner au côté d'envoi un petit délai d'expiration. De cette façon, l'auditeur reste à l'écoute jusqu'à ce que vous le contactiez, et une fois que les données cessent de couler, le client expirera, s'arrêtera et emmènera l'auditeur avec lui. À moins que le réseau intervenant ne soit lourd de problèmes, cela devrait être complètement fiable et vous pouvez toujours augmenter le délai d'attente. Un exemple typique de quelque chose de "rsh" est souvent utilisé pour: d'un côté,

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

puis de l'autre côté

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

transférera le contenu d'un répertoire d'une machine à une autre, sans avoir à se soucier des fichiers .rhosts, des comptes d'utilisateurs ou des configurations inetd à chaque extrémité.