Я пытаюсь отправить сообщение через netcat. После отправки сообщения, netcatнеобходимо прекратить.

Я пробовал следующее:

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

В -qопции говорится:

-q секунд

после EOF на stdin, подождите указанное количество секунд и затем выйдите. Если секунды отрицательны, ждите вечно.

Но

nc -q0 -u localhost 4300 < message.bin

тоже не работает.

Что мне не хватает?

Предполагая, что после отправки EOF соединение будет бездействовать, вы можете использовать -w timeoutопцию, которая работает, чтобы timeoutбыть равной нулю (в отличие от глупой -qопции ...)

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

Без -qфлага ваш экземпляр netcatбудет ждать вечно. В UDP нет сообщения «конец потока», поэтому нет возможности netcatузнать, что и stdin, и сетевое соединение завершены.

Например, при использовании TCP / IP это работает как ожидалось:

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

Но, как вы определили, использование UDP / IP никогда не заканчивается:

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

Это где -qфлаг входит. Но, к сожалению, он не принимает значение 0. Это также не будет принимать нецелые значения. Вот лучшая альтернатива, которую я могу предложить, не прибегая к timeoutкакой-либо внешней утилите:

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

Даже здесь невозможно netcatизящно провести время прослушивания . (Параметр -wтайм-аута игнорируется и не -qимеет значения.) Нечто подобное может быть полезно в практической ситуации, так что его netcatубивают через 90 секунд:

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

УДП

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

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

ТСР

# listen on receiver
nc -l localhost -p 4300

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

Наткнулся на это, когда гуглил по поводу примерно такой же проблемы. Выяснилось, что проблема заключалась в том, что netcat был убит bash сразу после того, как все данные были засосаны, без какого-либо шанса получить ответ.

Моим решением было добавить задержку после передачи данных, например:

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

С файлом это может выглядеть так:

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