Ich versuche eine Nachricht durch zu senden netcat. Nach dem Senden der Nachricht netcatmuss beendet werden.

Ich habe folgendes versucht:

cat tsmmessage.bin | nc -u localhost 4300
nc -u localhost 4300 < message.bin

Die -qOption 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?

Angenommen, nach dem Senden der EOF-Verbindung bleibt die -w timeoutOption inaktiv, können Sie die Option verwenden, die timeoutgleich Null ist (im Gegensatz zur dummen -qOption ...).

cat tsmmessage.bin | nc -u localhost 4300 -w0

Ohne die -qFlagge wird Ihre Instanz für netcatimmer warten. Es gibt keine "End of Stream" -Nachricht mit UDP, daher gibt es keine Möglichkeit netcatzu wissen, dass sowohl stdin als auch die Netzwerkverbindung beendet wurden.

Bei Verwendung von TCP / IP funktioniert dies beispielsweise wie erwartet:

nc -l localhost 4300                     # Window 1
nc localhost 4300 </etc/group            # Window 2

Aber wie Sie festgestellt haben, endet dies mit UDP / IP nie:

nc -u -l localhost 4300                  # Window 1
nc -u localhost 4300 </etc/group         # Window 2

Hier kommt die -qFlagge ins Spiel. Leider akzeptiert sie keinen Wert von 0. Es werden auch keine nicht ganzzahligen Werte akzeptiert. Hier ist die beste Alternative, die ich ohne Rückgriff auf timeoutoder ein anderes externes Dienstprogramm anbieten kann :

nc -u -l localhost 4300                  # Window 1
nc -q 1 -u localhost 4300 </etc/group    # Window 2

Selbst hier ist es nicht möglich, die Hörzeit netcatelegant zu gestalten. (Die -wTimeout-Option wird ignoriert und -qist irrelevant.) So etwas kann in einer praktischen Situation hilfreich sein, sodass das netcatnach 90 Sekunden beendet wird:

timeout 90 nc -u -l localhost 4300       # Window 1
nc -q 1 -u localhost 4300 </etc/group    # Window 2

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:

(echo INFO; sleep 1) | nc redis.service.consul 6379

Mit einer Datei kann dies folgendermaßen aussehen:

(cat tsmmessage.bin; sleep 5) | nc -u localhost 4300

udp

# listen on receiver
nc -u -l localhost -p 4300

# sender
cat tsmmessage.bin | nc -u -N -q 0 localhost 4300

tcp

# listen on receiver
nc -l localhost -p 4300

# sender
cat tsmmessage.bin | nc -N localhost 4300