Como saber quando NC é feito transferindo um arquivo

Question

Existe uma maneira de saber quando o netcat é feito transferindo um arquivo entre máquinas?

Comandos atuais:

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

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

A transferência acontece, mas não há indicação visual de que ela foi concluída.

    

Answer 1

Primeiro algum histórico

Existem diferentes versões de nc , como você pode encontrar em nc (1) - página man do Linux ou nc (1) Manual de Comandos Gerais do BSD a conexão deve ser encerrada logo após a transferência. Há um exemplo dado em ambos os sites vinculados:

Start by using nc to listen on a specific port, with output captured into a file:

$ nc -l 1234 > filename.out

Using a second machine, connect to the listening nc process, feeding it the file which is to be transferred:

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

After the file has been transferred, the connection will close automatically.

Seu netcat não encerra a conexão após a transferência, portanto é diferente do (s) descrito (s) acima. Ele se comporta como o meu, o Netcat 1.10 no Debian Jessie. Esse comportamento está documentado em /usr/share/doc/netcat-traditional/README.gz (na minha máquina), o ousadia é meu:

In the simplest usage, "nc host port" creates a TCP connection to the given port on the given target host. Your standard input is then sent to the host, and anything that comes back across the connection is sent to your standard output. This continues indefinitely, until the network side of the connection shuts down. Note that this behavior is different from most other applications which shut everything down and exit after an end-of-file on the standard input.

Este é o raciocínio por trás desse comportamento:

You may be asking "why not just use telnet to connect to arbitrary ports?" Valid question, and here are some reasons. Telnet has the "standard input EOF" problem, so one must introduce calculated delays in driving scripts to allow network output to finish. This is the main reason netcat stays running until the network side closes.

A Wikipedia tem um resumo das diferentes implementações . Eu não posso nomear diferenças embora. Talvez outra pessoa possa?

Agora, soluções

1

Você pode dizer a nc para sair depois que o arquivo for lido. Esta opção é útil:

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

Se você usar este comando no final do envio:

nc -q 0 MachineIP Port < test.txt

nc será encerrado 0 segundo após a leitura do EOF, ou seja, logo após o término do arquivo. Em seguida, ele será encerrado e, assim, o recebimento será nc .

Se você quer saber o que acontece se os pacotes não passarem, aqui está um comentário de Juraj.

When all packets don't come across, system will detect this and retransmit them without application noticing (or if not possible, application will get timeout error). Reliable delivery is the purpose of TCP protocol provided by OS kernel, which nc uses. You can request UDP protocol that does not do this, using nc -u but this is not the case.

2

Há um exemplo original no README.gz , que é baseado no tempo limite -w e não exige que a opção -q esteja presente na sua implementação.

Netcat can be used as a simple data transfer agent, and it doesn't really matter which end is the listener and which end is the client -- input at one side arrives at the other side as output. It is helpful to start the listener at the receiving side with no timeout specified, and then give the sending side a small timeout. That way the listener stays listening until you contact it, and after data stops flowing the client will time out, shut down, and take the listener with it. Unless the intervening network is fraught with problems, this should be completely reliable, and you can always increase the timeout. A typical example of something "rsh" is often used for: on one side,

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

and then on the other side

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

will transfer the contents of a directory from one machine to another, without having to worry about .rhosts files, user accounts, or inetd configurations at either end.