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 netcat
non 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 nc
di 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
nc
si 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 nc
utilizza. Puoi richiedere il protocollo UDP che non lo fa, usando nc -u
ma non è così.
2
C'è un esempio originale nel summenzionato README.gz
, che si basa sul -w
timeout e non richiede l' -q
opzione 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à.