Estou tentando enviar uma mensagem netcat. Depois de enviar a mensagem, netcatdeve terminar.

Eu tentei o seguinte:

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

A -qopção declara:

-q segundos

após o EOF no stdin, aguarde o número especificado de segundos e saia. Se os segundos forem negativos, espere para sempre.

Mas

nc -q0 -u localhost 4300 < message.bin

também não funciona.

o que estou perdendo?

Supondo que após o envio da conexão EOF fique ocioso, você pode usar -w timeout opção, que funciona por timeoutser igual a zero (ao contrário da -qopção estúpida ...)

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

Sem a -qbandeira da sua instâncianetcat irá esperar para sempre. Não há mensagem "fim do fluxo" com o UDP, portanto não há como netcatsaber que o stdin e a conexão de rede foram finalizados.

Por exemplo, usando TCP / IP, isso funciona conforme o esperado:

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

Mas, como você determinou, o uso de UDP / IP nunca termina:

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

É aqui que a -qbandeira entra. Mas, infelizmente, ela não aceita um valor de 0. Também não aceita valores não inteiros. Aqui está a melhor alternativa que posso oferecer sem recorrer a timeoutoutro utilitário externo:

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

Mesmo aqui, não é possível ter o netcattempo de audição graciosamente. (A -wopção de tempo limite é ignorada e -qé irrelevante.) Algo assim pode ser útil em uma situação prática, de modo que a netcateliminação seja interrompida após 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

Tropeçamos nisso quando pesquisamos no Google sobre praticamente o mesmo problema. O problema foi que o netcat foi morto pelo bash logo após todos os dados terem sido sugados, sem nenhuma chance de receber a resposta.

Minha solução para isso foi adicionar algum atraso após a canalização dos dados, assim:

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

Com um arquivo, isso pode se parecer com:

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