Jak się dowiedzieć, kiedy NC zakończy przesyłanie pliku

Czy istnieje sposób, aby wiedzieć, kiedy Netcat przesyła plik między komputerami?

Bieżące polecenia:

Maszyna nr 2: nc -lp 5555 > test.txt

Maszyna nr 1: nc MachineIP Port < test.txt

Przeniesienie ma miejsce, ale nie ma wizualnego wskazania, że ​​zostało zakończone.

Najpierw jakieś tło

Istnieją różne wersje nc, jak można znaleźć na nc (1) - Linux man manual lub nc (1) BSD General Commands Manual, połączenie powinno zostać zamknięte zaraz po transferze. Na obu połączonych stronach podano przykład:

Zacznij od użycia nc do nasłuchu na określonym porcie, z wyjściem przechwyconym do pliku:

$ nc -l 1234 > filename.out

Za pomocą drugiego komputera połącz się z procesem nasłuchiwania, podając mu plik, który ma zostać przesłany:

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

Po przesłaniu pliku połączenie zostanie automatycznie zamknięte.

Twoje połączenie netcatnie zostanie zamknięte po transferze, więc różni się od tego opisanego powyżej. Zachowuje się jak mój, Netcat 1.10 na Debian Jessie. To zachowanie jest udokumentowane w /usr/share/doc/netcat-traditional/README.gz(na moim komputerze), pogrubienie jest moje:

W najprostszym użyciu „port hosta nc” tworzy połączenie TCP z danym portem na danym hoście docelowym. Standardowe dane wejściowe są następnie wysyłane do hosta, a wszystko, co wraca przez połączenie, jest wysyłane na standardowe wyjście. Trwa to w nieskończoność, dopóki strona sieciowa połączenia nie zostanie wyłączona. Zauważ, że to zachowanie różni się od większości innych aplikacji, które zamykają wszystko i wychodzą po zakończeniu pliku na standardowym wejściu.

Oto uzasadnienie tego zachowania:

Być może pytasz „dlaczego nie użyć telnetu do łączenia się z dowolnymi portami?” Ważne pytanie, a oto kilka powodów. Telnet ma problem z „standardowym wejściem EOF”, dlatego należy wprowadzić obliczone opóźnienia w skryptach sterujących, aby umożliwić zakończenie działania wyjścia sieciowego. Jest to główny powód, dla którego netcat działa, dopóki strona sieci nie zostanie zamknięta.

Wikipedia ma wiele różnych wdrożeń . Nie umiem jednak wymienić różnic. Może ktoś inny może?

Teraz rozwiązania

1

Możesz powiedzieć, ncaby zakończyć po odczytaniu pliku. Ta opcja jest przydatna:

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

Jeśli użyjesz tego polecenia po stronie wysyłającej:

nc -q 0 MachineIP Port < test.txt

ncwyjdzie 0 sekund po odczytaniu EOF, czyli zaraz po zakończeniu pliku. Następnie wyjdzie, podobnie jak koniec odbierający nc.

Jeśli zastanawiasz się, co się stanie, jeśli pakiety nie przejdą, oto komentarz Juraja.

Kiedy wszystkie pakiety nie napotkają, system wykryje to i wyśle ​​je ponownie bez powiadomienia aplikacji (lub jeśli nie będzie to możliwe, aplikacja otrzyma błąd przekroczenia limitu czasu). Niezawodne dostarczanie jest celem protokołu TCP zapewnianego przez jądro systemu operacyjnego, które ncwykorzystuje. Możesz zażądać protokołu UDP, który tego nie robi, używając, nc -uale tak nie jest.

2)

We wspomnianym powyżej jest oryginalny przykład README.gz, który opiera się na przekroczeniu -wlimitu czasu i nie wymaga -qopcji obecności w implementacji.

Netcat może być używany jako prosty agent przesyłania danych i tak naprawdę nie ma znaczenia, który koniec jest odbiornikiem, a który klientem - dane wejściowe z jednej strony docierają do drugiej jako dane wyjściowe. Pomocne jest rozpoczęcie nasłuchiwania po stronie odbierającej bez określonego limitu czasu, a następnie niewielkie opóźnienie po stronie wysyłającej. W ten sposób słuchacz pozostaje nasłuchiwany, dopóki się z nim nie skontaktujesz, a gdy dane przestaną płynąć, klient przekroczy limit czasu, zamknie się i zabierze ze sobą słuchacza. O ile sieć interweniująca nie jest obarczona problemami, powinno to być całkowicie niezawodne i zawsze można zwiększyć limit czasu. Typowy przykład czegoś „rsh” jest często używany do: z jednej strony,

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

a potem po drugiej stronie

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

przeniesie zawartość katalogu z jednego komputera na drugi, bez konieczności martwienia się o pliki .rhosts, konta użytkowników lub konfiguracje inetd na obu końcach.