Come sapere quando NC ha terminato il trasferimento di un file


11

C'è un modo per sapere quando netcat ha finito di trasferire un file tra macchine?

Comandi correnti:

Macchina n. 2: nc -lp 5555 > test.txt

Macchina n. 1: nc MachineIP Port < test.txt

Il trasferimento avviene, ma non vi è alcuna indicazione visiva del completamento.

Risposte:


19

Prima alcuni retroscena

Esistono diverse versioni di nc, come puoi trovare su nc (1) - Linux man page o nc (1) BSD General Commands Manual, la connessione dovrebbe chiudersi subito dopo il trasferimento. C'è un esempio fornito su entrambi i siti collegati:

Inizia utilizzando nc per ascoltare su una porta specifica, con l'output acquisito in un file:

$ nc -l 1234 > filename.out

Usando una seconda macchina, connettiti al processo di ascolto nc, alimentandolo con il file che deve essere trasferito:

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

Dopo che il file è stato trasferito, la connessione si chiuderà automaticamente.

Il tuo netcatnon interrompe la connessione dopo il trasferimento, quindi è diverso da quello descritto sopra. Si comporta come il mio, Netcat 1.10 su Debian Jessie. Questo comportamento è documentato in /usr/share/doc/netcat-traditional/README.gz(sulla mia macchina), il grassetto è mio:

Nell'uso più semplice, "nc host port" crea una connessione TCP alla porta specificata sull'host di destinazione indicato. L'input standard viene quindi inviato all'host e tutto ciò che ritorna attraverso la connessione viene inviato all'output standard. Questo continua indefinitamente, fino a quando il lato della rete della connessione non si arresta. Si noti che questo comportamento è diverso dalla maggior parte delle altre applicazioni che chiudono tutto ed escono dopo un end-of-file sull'input standard.

Ecco il ragionamento alla base di questo comportamento:

Forse ti stai chiedendo "perché non utilizzare Telnet per collegarti a porte arbitrarie?" Domanda valida, e qui ci sono alcuni motivi. Telnet presenta il problema "EOF di input standard", pertanto è necessario introdurre ritardi calcolati negli script di guida per consentire il completamento dell'output di rete. Questo è il motivo principale per cui netcat rimane in esecuzione fino alla chiusura del lato rete .

Wikipedia ha una serie di diverse implementazioni . Non posso nominare le differenze però. Forse qualcun altro può?


Ora, soluzioni

1

Puoi dire ncdi uscire dopo aver letto il file. Questa opzione è utile:

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

Se si utilizza questo comando alla fine dell'invio:

nc -q 0 MachineIP Port < test.txt

ncsi chiuderà 0 secondi dopo aver letto EOF, ovvero subito dopo la fine del file. Quindi uscirà e così anche la ricezione nc.

Se ti chiedi cosa succede se i pacchetti non attraversano, ecco un commento di Juraj.

Quando tutti i pacchetti non vengono rilevati, il sistema lo rileverà e li ritrasmetterà senza che l'applicazione lo noti (o, se non è possibile, l'applicazione otterrà un errore di timeout). La consegna affidabile è lo scopo del protocollo TCP fornito dal kernel del sistema operativo, che ncutilizza. Puoi richiedere il protocollo UDP che non lo fa, usando nc -uma non è così.

2

C'è un esempio originale nel summenzionato README.gz, che si basa sul -wtimeout e non richiede l' -qopzione per essere presente nella tua implementazione.

Netcat può essere utilizzato come un semplice agente di trasferimento dati e non importa quale estremità sia l'ascoltatore e quale estremità sia il client - l'input da un lato arriva dall'altro lato come output. È utile avviare l'ascoltatore dal lato di ricezione senza alcun timeout specificato, quindi assegnare un piccolo timeout al lato di invio. In questo modo l'ascoltatore rimane in ascolto fino a quando non lo si contatta e, dopo che i dati smettono di scorrere, il client scade, si spegne e porta con sé l'ascoltatore. A meno che la rete non sia piena di problemi, questo dovrebbe essere completamente affidabile e puoi sempre aumentare il timeout. Un esempio tipico di qualcosa di "rsh" è spesso usato per: da un lato,

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

e poi dall'altra parte

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

trasferirà il contenuto di una directory da una macchina all'altra, senza doversi preoccupare di file .rhosts, account utente o configurazioni inetd alle due estremità.


Non riesco a farlo funzionare. Quando faccio -q dice che il comando non esiste. Vedo -w sembra simile ma questo non causa la chiusura della connessione
Anthony Russell,

Qual è la tua ncversione? Per controllare:, nc -hprima riga.

eh sì, è piuttosto vecchio. Sono su una vecchia immagine di Linux. Lo aggiornerò e lo proverò ancora
Anthony Russell,

Ho aggiornato la mia risposta.

1
Quando tutti i pacchetti non vengono rilevati, il sistema operativo lo rileverà e li ritrasmetterà senza che l'applicazione lo noti (o se ciò non riesce ancora, l'applicazione otterrà un errore di timeout). La consegna affidabile è lo scopo del protocollo TCP fornito dal kernel del sistema operativo, che nc utilizza. Puoi richiedere il protocollo UDP che non lo fa, usando nc -u ma non è così.
Juraj,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.