Próbuję wysłać wiadomość przez netcat
. Po wysłaniu wiadomości netcat
należy zakończyć.
Próbowałem następujące:
cat tsmmessage.bin | nc -u localhost 4300
nc -u localhost 4300 < message.bin
Te -q
stany opcyjne:
-q sekund
po EOF na standardowe wejście, poczekaj określoną liczbę sekund, a następnie zakończ. Jeśli sekundy są ujemne, poczekaj wiecznie.
Ale
nc -q0 -u localhost 4300 < message.bin
też nie działa.
czego mi brakuje?
-q
.invalid wait-time 0
Bez
-q
flagi instancjanetcat
będzie czekać wiecznie. UDP nie ma komunikatu „koniec strumienia”, więc nie ma sposobu,netcat
aby wiedzieć, że zarówno standardowe połączenie , jak i połączenie sieciowe zostały zakończone.Na przykład przy użyciu protokołu TCP / IP działa to zgodnie z oczekiwaniami:
Ale jak ustaliłeś, użycie UDP / IP nigdy się nie kończy:
W tym miejscu
-q
pojawia się flaga. Niestety nie przyjmuje ona wartości0
. Nie przyjmie również wartości innych niż całkowite. Oto najlepsza alternatywa, jaką mogę zaoferować bez konieczności korzystania ztimeout
innych zewnętrznych narzędzi:Nawet tutaj nie można
netcat
z wdziękiem spędzać czasu na słuchaniu . (Opcja-w
limitu czasu jest ignorowana i nie-q
ma znaczenia.) Coś takiego może być przydatne w praktycznej sytuacji, abynetcat
zabić ją po 90 sekundach:źródło
-q 0
pracuje dla mnie.udp
tcp
źródło
Natknąłem się na to, kiedy Googling dotyczył prawie tego samego problemu. Okazało się, że problem polegał na tym, że netcat został zabity przez bash zaraz po tym, jak wszystkie dane zostały wessane, bez szansy na odpowiedź.
Moim rozwiązaniem było dodanie opóźnienia po skończeniu przesyłania danych:
Z plikiem może to wyglądać następująco:
źródło
netcat
nadal nie zamyka się posleep
zakończeniu. Spodziewałbym się, że pierwsza linia poleceń powróci do monitu po 1 sekundzie, ale tak nie jest.-q 1
? tj.(echo INFO; sleep 1) | nc -q 1 redis.service.consul 6379
?-q
prac wszystko, nawet na przykładzie w moim oryginalne pytanie. Od tego czasu przeniosłem się na nowszą wersję Ubuntu, może to powoduje różnicę.