Estoy tratando de enviar un mensaje netcat. Después de enviar el mensaje, netcatdebe terminar.

He intentado lo siguiente:

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

La -qopción dice:

-q segundos

después de EOF en stdin, espere el número de segundos especificado y luego salga. Si los segundos son negativos, espera para siempre.

Pero

nc -q0 -u localhost 4300 < message.bin

Tampoco funciona.

¿Qué me estoy perdiendo?

Suponiendo que después de enviar la conexión EOF permanecerá inactiva, puede usar la -w timeoutopción, que funciona para timeoutser igual a cero (a diferencia de la -qopción estúpida ...)

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

Sin la -qbandera, su instancia netcatesperará para siempre. No hay un mensaje de "fin de transmisión" con UDP, por lo que no hay forma de netcatsaber que tanto la conexión estándar como la conexión de red han finalizado.

Por ejemplo, usando TCP / IP esto funciona como se esperaba:

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

Pero como ha determinado, usando UDP / IP esto nunca termina:

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

Aquí es donde -qentra la bandera. Pero desafortunadamente no acepta un valor de 0. Tampoco aceptará valores no enteros. Aquí está la mejor alternativa que puedo ofrecer sin recurrir a ninguna timeoutotra utilidad externa:

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

Incluso aquí, no es posible tener el netcattiempo de escucha con gracia. (La -wopción de tiempo de espera se ignora y -qes irrelevante). Algo como esto podría ser útil en una situación práctica, de modo que netcatse elimine después de 90 segundos:

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

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

Tropecé con esto cuando busqué en Google casi el mismo problema. Resultó que el problema era que netcat fue asesinado por bash justo después de que se absorbieron todos los datos, sin tener ninguna oportunidad de recibir la respuesta.

Mi solución a esto fue agregar algún retraso después de canalizar los datos, así:

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

Con un archivo esto puede verse así:

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