Sto cercando di inviare un messaggio netcat. Dopo aver inviato il messaggio, netcatdeve terminare.

Ho provato quanto segue:

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

L' -qopzione afferma:

-q secondi

dopo EOF su stdin, attendere il numero specificato di secondi e poi uscire. Se i secondi sono negativi, aspetta per sempre.

Ma

nc -q0 -u localhost 4300 < message.bin

inoltre non funziona.

Cosa mi sto perdendo?

Supponendo che dopo l'invio della connessione EOF rimarrà inattivo, è possibile utilizzare l' -w timeoutopzione, che funziona per timeoutessere uguale a zero (a differenza -qdell'opzione stupida ...)

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

Senza la -qbandiera la tua istanza netcataspetterà per sempre. Non esiste un messaggio "end of stream" con UDP, quindi non c'è modo netcatdi sapere che sia stdin che la connessione di rete sono terminate.

Ad esempio, utilizzando TCP / IP funziona come previsto:

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

Ma come hai determinato, usando UDP / IP questo non finisce mai:

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

È qui -qche entra in gioco la bandiera. Ma sfortunatamente non accetta un valore di 0. Inoltre, non accetta valori non interi. Ecco la migliore alternativa che posso offrire senza ricorrere a timeoutqualche altra utility esterna:

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

Anche qui, non è possibile avere il netcattempo di ascolto con grazia. (L' -wopzione di timeout viene ignorata ed -qè irrilevante.) Qualcosa del genere potrebbe essere utile in una situazione pratica, in modo che netcatvenga ucciso dopo 90 secondi:

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

Ci siamo imbattuti in questo quando Google su praticamente lo stesso problema. Si è scoperto che il problema era che netcat veniva ucciso da bash subito dopo che tutti i dati venivano risucchiati, senza avere alcuna possibilità di ricevere la risposta.

La mia soluzione è stata quella di aggiungere qualche ritardo dopo il piping dei dati, in questo modo:

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

Con un file questo può apparire come:

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