Utilizzo di pipe denominate in / out per una connessione TCP

15

Sono stato un po 'stanco di far funzionare questo per un po' di tempo, quindi sospetto una sorta di fondamentale fraintendimento sul modo in cui i tubi funzionano è la causa principale dei miei problemi.

Il mio obiettivo è quello di avviare una connessione TCP ad un host remoto tramite netcate avere due named pipe sul filesystem: una da cui i processi possono leggere per ottenere i dati in entrata, e altri che i processi possono scrivere su quelli che servono come dati in uscita. Attualmente sto usando la seguente costruzione:

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

Da qui, vorrei consentire ad altri processi di leggere e scrivere su / da questa connessione TCP aperta. Questo dovrebbe "funzionare" o c'è un motivo per cui un costrutto come questo non può funzionare?

Quello che sembra accadere al momento è che posso leggere outsenza problemi, ma quando scrivo inottengo un output che menziona una pipe rotta e tutte le comunicazioni successive sembrano essere morte. Pensieri?

(Correlato: originariamente ho usato:

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

ma ho trovato per bloccare in attesa di input. Sono curioso anche di questo, ma probabilmente è meglio affrontarlo in una domanda separata.)

— noffle
fonte

6

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

Penso che il problema sia che catuscirà non appena riceverà un messaggio EOFdalla outpipe. E quando catesce, anche il resto della pipeline (incluso netcat) viene chiuso.

Prova invece qualcosa del genere:

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

Pertanto, catviene riavviato tutte le volte che è necessario e qualsiasi EOFs visualizzata nel outtubo viene gestita in modo efficace.

— Steven Monday
fonte

Ci ho provato, ma ricevo ancora write(stdout): Broken pipedopo (o poco dopo) la scrittura sulla outpipe.

— noffle

2

Avevo affrontato anche questo problema. Il problema principale è netcat. È un ottimo strumento, ma chiude la connessione quando viene chiuso uno dei suoi descrittori di file di input o output collegati. Non fa nulla quando il server non è in ascolto ed esce quando l'altro peer è chiuso. Se si imposta correttamente il server e si mantengono aperti i descrittori dei file, funzionerà. Ad esempio ho testato il seguente scenario e ha funzionato molto bene: in una configurazione terminale un server echo (l'ho impostato come di seguito):

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

ora in un altro terminale imposta la tua connessione fifo al tuo server:

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

stampa qualunque server ti mandi (e tienilo in esecuzione, se usi infifo in un'applicazione che chiude un'estremità al suo termine, netcatchiude la connessione)

cat in &

e nello stesso terminale:

cat > out

ora qualunque cosa tu digiti verrà nuovamente stampata (dopo aver premuto Invio). Chiudendo questo comando si chiuderà anche la connessione.

— saeedn
fonte

Vedo che non è il caso quando lo provo da solo, ma perché netcat -t -l -p 4000 < loopFF | tee loopFFnon provoca un ciclo di feedback infinito con se stesso?

— noffle

@noffle perché, come ho detto, netcatsi chiuderà ogni volta che si chiude una delle sue connessioni di rete. Se chiudi il client (che invia una stringa e riceve la stessa stringa), anche il netcatserver verrà chiuso. Ho scritto un codice server per me stesso in questo caso che si forgia per gestire più client e riconnetterli.

— Saeedn,

2

L'analisi di Steven Monday mi sta bene: catritorna dopo la tua prima scrittura outperché il FIFO lo è empty. Per evitare ciò, la soluzione è quella di mantenere un processo con il fifo aperto in modalità di scrittura, il primo catnell'esempio seguente:

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

(Il file out-pid è il modo per fermare il tutto:. kill -9 $(cat out-pid))

Un altro esempio qui .

— jfg956
fonte