J'essaie d'envoyer un message netcat. Après l'envoi du message, netcatdoit se terminer.

J'ai essayé ce qui suit:

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

L' -qoption indique:

-q secondes

après EOF sur stdin, attendez le nombre de secondes spécifié, puis quittez. Si les secondes sont négatives, attendez indéfiniment.

Mais

nc -q0 -u localhost 4300 < message.bin

ne fonctionne pas non plus.

Qu'est-ce que je rate?

En supposant qu'après l'envoi de la connexion EOF restera inactive, vous pouvez utiliser l' -w timeoutoption, qui fonctionne pour timeoutêtre égale à zéro (contrairement à l' -qoption stupide ...)

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

Sans le -qdrapeau, votre instance netcatattendra pour toujours. Il n'y a pas de message de "fin de flux" avec UDP, donc il n'y a aucun moyen netcatde savoir que stdin et la connexion réseau sont terminés.

Par exemple, en utilisant TCP / IP, cela fonctionne comme prévu:

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

Mais comme vous l'avez déterminé, en utilisant UDP / IP, cela ne finit jamais:

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

C'est là que le -qdrapeau entre en jeu. Mais malheureusement, il n'accepte pas une valeur de 0. Il n'accepte pas non plus les valeurs non entières. Voici la meilleure alternative que je puisse offrir sans recours timeoutni autre utilité externe:

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

Même ici, il n'est pas possible de prolonger le netcattemps d' écoute avec élégance. (L' -woption de délai d'attente est ignorée et -qn'est pas pertinente.) Quelque chose comme cela pourrait être utile dans une situation pratique, de sorte que le netcatsoit tué après 90 secondes:

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

Je suis tombé dessus lorsque Google a regardé à peu près le même problème. Il s'est avéré que le problème était que netcat a été tué par bash juste après que toutes les données ont été aspirées, sans avoir la moindre chance de recevoir la réponse.

Ma solution à cela a été d'ajouter un peu de retard après avoir canalisé les données, comme ceci:

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

Avec un fichier, cela peut ressembler à:

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