Uso de canalizaciones con nombre de entrada / salida para una conexión TCP

15

He estado jugando con hacer que esto funcione por un tiempo, así que sospecho que algún tipo de malentendido fundamental sobre cómo funcionan las tuberías es la causa principal de mis problemas.

Mi objetivo es iniciar una conexión TCP a algún host remoto a través de netcaty tener dos canales con nombre en el sistema de archivos: uno que los procesos puedan leer para obtener datos entrantes, y otro que los procesos puedan escribir para que sirvan como datos salientes. Actualmente estoy usando la siguiente construcción:

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

Desde aquí, me gustaría permitir que otros procesos lean y escriban en / desde esta conexión TCP abierta. ¿Debería esto "simplemente funcionar", o hay una razón por la cual una construcción como esta no puede funcionar?

Lo que parece suceder en este momento es que puedo leer outsin problemas, pero cuando escribo inme sale un mensaje que menciona una tubería rota y toda la comunicación posterior parece estar muerta. Pensamientos?

(Relacionado: originalmente usé:

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

pero encontró que bloquea la espera de entrada. Tengo curiosidad por esto también, pero probablemente se aborde mejor en una pregunta separada).

— noffle
fuente

6

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

Creo que el problema es que catva a salir tan pronto como se reciba una EOFde la outtubería. Y cuando catsale, el resto de la tubería (incluido netcat) también se termina.

Pruebe algo como esto en su lugar:

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

Por lo tanto, catse reinicia tantas veces como sea necesario, y cualquier EOFmensaje que aparezca en la outtubería se maneja de manera efectiva.

— Steven Monday
fuente

Intenté esto, pero aún recibo write(stdout): Broken pipedespués (o poco después) de escribir en la outtubería.

— noffle

2

También me enfrenté a este problema. El principal problema es netcat. Es una gran herramienta, pero cierra la conexión cuando se cierra uno de sus descriptores de archivos de entrada o salida conectados. No hace nada cuando el servidor no está escuchando y se cierra cuando el otro par está cerrado. Siempre que configure el servidor correctamente y mantenga abiertos los descriptores de sus archivos, funcionará. Por ejemplo, probé el siguiente escenario y funcionó muy bien: en una configuración de terminal, un servidor echo (lo configuré como a continuación):

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

ahora en otra terminal configure su conexión de Fifo a su servidor

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

imprima lo que le envíe el servidor (y manténgalo en funcionamiento, si usa infifo en una aplicación que cierra un extremo al finalizar, netcatcierra la conexión)

cat in &

y en la misma terminal:

cat > out

ahora lo que escriba se imprimirá nuevamente (después de presionar Enter). Cerrar este comando también cerrará la conexión.

— saeedn
fuente

Puedo ver que no es así cuando lo pruebo yo mismo, pero ¿por qué netcat -t -l -p 4000 < loopFF | tee loopFFno causa un ciclo de retroalimentación infinito consigo mismo?

— noffle

@noffle porque, como dije, netcatse cerrará cada vez que se cierre una de sus conexiones de red. Si cierra el cliente (que envía una cadena y recibe la misma cadena), el netcatservidor también se cerrará. Escribí un código de servidor para mí en este caso que se bifurca para manejar múltiples clientes y reconectarlos.

— saeedn

2

El análisis de Steven Monday me parece bien: catregresa después de su primera escritura outporque el quince es empty. Para evitar eso, la solución es mantener un proceso con el fifo abierto en modo de escritura, el primero caten el siguiente ejemplo:

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

(El archivo out-pid es la forma de detener todo:. kill -9 $(cat out-pid))

Otro ejemplo aquí .

— jfg956
fuente