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

15

Estou mexendo nisso há algum tempo, então suspeito que algum tipo de mal-entendido fundamental sobre como os tubos funcionam é a causa raiz dos meus problemas.

Meu objetivo é iniciar uma conexão TCP com algum host remoto via netcate ter dois pipes nomeados no sistema de arquivos: um que os processos podem ler para obter dados recebidos e outro que os processos podem gravar para servir como dados de saída. 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 leiam e gravem para / a partir dessa conexão TCP aberta. Isso deveria "funcionar" ou existe uma razão pela qual uma construção como essa não pode funcionar?

O que parece acontecer no momento é que eu posso ler outsem problemas, mas quando escrevo in, recebo uma saída mencionando um cano quebrado e toda a comunicação subsequente parece estar morta. Pensamentos?

(Relacionado: Eu originalmente usei:

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

mas o encontrou bloqueando a espera pela entrada. Também estou curioso sobre isso, mas provavelmente será melhor abordado em uma pergunta separada.)

— noffle
fonte

6

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

Penso que o problema é que catsairá assim que receber um EOFdo outtubo. E quando catsai, o restante do pipeline (inclusive netcat) também é encerrado.

Tente algo assim:

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

Assim, caté reiniciado quantas vezes for necessário e todos os EOFs que aparecem no outtubo são efetivamente manipulados.

— Steven segunda-feira
fonte

Eu tentei isso, mas ainda recebo write(stdout): Broken pipedepois (ou logo depois) da gravação no outpipe.

— Noffle

2

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

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

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

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

imprima o que o servidor enviar para você (e mantenha-o em execução, se você usar o infifo em um aplicativo que fecha uma extremidade em sua terminação, netcatfecha 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.

— saeedn
fonte

Percebo que não é o caso quando tento fazer isso sozinho, mas por que netcat -t -l -p 4000 < loopFF | tee loopFFnão causa um loop infinito de feedback consigo mesmo?

— Noffle

@offoff porque, como eu disse, netcatfecha sempre que uma de suas conexões de rede fecha. Se você fechar o cliente (que envia uma string e recebe a mesma), o netcatservidor também será fechado. Eu escrevi um código de servidor para mim neste caso, que se bifurca para lidar com vários clientes e reconectar clientes.

— saeedn

2

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

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

(O arquivo out-pid é a maneira de parar a coisa toda:. kill -9 $(cat out-pid))

Outro exemplo aqui .

— jfg956
fonte