Ich versuche eine Nachricht durch zu senden netcat
. Nach dem Senden der Nachricht netcat
muss beendet werden.
Ich habe folgendes versucht:
cat tsmmessage.bin | nc -u localhost 4300
nc -u localhost 4300 < message.bin
Die -q
Option lautet:
-q Sekunden
Warten Sie nach EOF auf stdin die angegebene Anzahl von Sekunden und beenden Sie dann. Wenn Sekunden negativ sind, warten Sie für immer.
Aber
nc -q0 -u localhost 4300 < message.bin
funktioniert auch nicht.
Was vermisse ich?
-q
.invalid wait-time 0
Ohne die
-q
Flagge wird Ihre Instanz fürnetcat
immer warten. Es gibt keine "End of Stream" -Nachricht mit UDP, daher gibt es keine Möglichkeitnetcat
zu wissen, dass sowohl stdin als auch die Netzwerkverbindung beendet wurden.Bei Verwendung von TCP / IP funktioniert dies beispielsweise wie erwartet:
Aber wie Sie festgestellt haben, endet dies mit UDP / IP nie:
Hier kommt die
-q
Flagge ins Spiel. Leider akzeptiert sie keinen Wert von0
. Es werden auch keine nicht ganzzahligen Werte akzeptiert. Hier ist die beste Alternative, die ich ohne Rückgriff auftimeout
oder ein anderes externes Dienstprogramm anbieten kann :Selbst hier ist es nicht möglich, die Hörzeit
netcat
elegant zu gestalten. (Die-w
Timeout-Option wird ignoriert und-q
ist irrelevant.) So etwas kann in einer praktischen Situation hilfreich sein, sodass dasnetcat
nach 90 Sekunden beendet wird:quelle
-q 0
funktioniert bei mir.Stolperte darüber, als Googeln über so ziemlich das gleiche Problem sprach. Es stellte sich heraus, dass Netcat direkt nach dem Absaugen aller Daten durch Bash getötet wurde, ohne die Chance zu haben, die Antwort zu erhalten.
Meine Lösung bestand darin, nach dem Weiterleiten der Daten eine gewisse Verzögerung hinzuzufügen:
Mit einer Datei kann dies folgendermaßen aussehen:
quelle
netcat
schließt immer noch nicht, wenn essleep
fertig ist. Ich würde erwarten, dass die erste Befehlszeile nach 1 Sekunde zur Eingabeaufforderung zurückkehrt, aber dies ist nicht der Fall.-q 1
? dh(echo INFO; sleep 1) | nc -q 1 redis.service.consul 6379
?-q
allem funktioniert auch das Beispiel in meiner ursprünglichen Frage. Ich bin seitdem auf eine neuere Version von Ubuntu umgestiegen, vielleicht verursacht das den Unterschied.udp
tcp
quelle