Я намагаюся надіслати повідомлення через netcat. Після відправлення повідомлення netcatнеобхідно припинити.

Я спробував таке:

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

У -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

tcp

# 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