Usando pipes nomeados de entrada / saída para uma conexão TCP

Question

Estou tentando fazer isso funcionar por um tempo agora, então suspeito que algum tipo de mal-entendido sobre como os canos funcionam é a causa dos meus problemas.

Meu objetivo é iniciar uma conexão TCP com algum host remoto por meio de netcat e ter dois canais nomeados no sistema de arquivos: um que os processos possam ler para obter dados de entrada e outros que possam gravar nesse servidor como saída dados. Atualmente, estou usando a seguinte construção:

mkfifo in
mkfifo out
cat out | netcat foo.bar.org 4000 > in &

A partir daqui, gostaria de permitir que outros processos lessem e escrevessem para / a partir desta conexão TCP aberta. Deveria isto "apenas funcionar", ou há uma razão pela qual um constructo como este não pode funcionar?

O que parece acontecer no momento é que eu posso ler out sem problema, mas quando escrevo para in eu saio mencionando um cano quebrado e toda a comunicação subsequente parece ser morto. Pensamentos?

(Relacionado: eu usei originalmente:

netcat foo.bar.org 4000 < out > in &

mas descobriu que ele bloqueia a espera pela entrada. Estou curioso sobre isso também, mas provavelmente é melhor abordar em uma questão separada.)

    

Answer 1

cat out | netcat foo.bar.org 4000 > in &

Acho que o problema é que cat sairá assim que receber um EOF do out pipe. E quando cat sai, o restante do pipeline (incluindo netcat ) é finalizado também.

Tente algo assim:

while true; do cat out; done | netcat foo.bar.org 4000 > in &

Assim, cat é reiniciado quantas vezes forem necessárias, e qualquer EOF s que aparece no canal out é efetivamente manipulado.

    

Answer 2

Eu já havia enfrentado esse problema também. O principal problema é netcat . É uma ótima ferramenta, mas fecha a conexão quando um de seus descritores de arquivo de entrada ou saída conectados está fechado. Não faz nada quando o servidor não está escutando e sai quando o outro par é fechado. Contanto que você configure o servidor corretamente e mantenha seus descritores de arquivos abertos, ele funcionará. Por exemplo, eu testei o seguinte cenário e funcionou muito bem: em uma configuração de terminal, um servidor de eco (eu configurei como abaixo):

mkfifo loopFF
netcat -t -l -p 4000 <loopFF | tee loopFF

agora em outro terminal, configure sua conexão fifo com seu servidor:

mkfifo in
mkfifo out
netcat 127.0.0.1 4000 <out >in &

imprima o que quer que o servidor envie para você (e mantenha-o em execução, se você usar in fifo em um aplicativo que fecha uma extremidade em sua terminação, netcat fecha a conexão)

cat in &

e no mesmo terminal:

cat > out

agora o que você digitar será impresso novamente (depois de pressionar Enter). Fechar este comando também fechará a conexão.

    

Answer 3

A análise de Steven Monday parece boa para mim: cat retorna após sua primeira gravação em out porque o fifo é empty . Para evitar isso, a solução é manter um processo com o fifo aberto no modo write, o primeiro cat no exemplo abaixo:

mkfifo in
mkfifo out
cat > out &
echo $! > out-pid
cat out | netcat foo.bar.org 4000 > in &

(O arquivo out-pid é o caminho para parar a coisa toda: kill -9 $(cat out-pid) .)

Outro exemplo aqui .