Come impostare un proxy di cambio di genere TCP persistente?

Ho un provider (A) che vuole inviarci dati tramite una connessione TCP in entrata. Sfortunatamente il servizio di consumo (B) non può ricevere connessioni TCP in entrata. Inoltre non ha un IP statico, un altro requisito.

Un modo per risolvere questo sarebbe un servizio che collega la porta TCP A in entrata a un'altra porta TCP B, in modo che il consumatore possa stabilire una connessione in uscita a B.

Questo non è un problema unico [1] [2] e con socat posso fare qualcosa di molto vicino a ciò che voglio:

socat -d -d -d -u TCP4-LISTEN:PORT-A,reuseaddr TCP4-LISTEN:PORT-B,reuseaddr

Tuttavia, ciò presenta i seguenti problemi:

• Se B si disconnette, non può riconnettersi. Con TCP4-LISTEN:PORT-B,reuseaddr,fork, può connettersi ma non riceve dati.
• B non può connettersi prima che A abbia stabilito una connessione (superabile)
• È possibile stabilire solo una connessione a PORT-B(superabile)

C'è un modo per regolare il comando in modo che diventi "permamento" e resistente ai guasti?

La domanda importante è: come reagirà A alla perdita di connessione o al rifiuto della connessione? Tutto ciò che presuppone che una singola connessione TCP rimarrà attiva per sempre sarà fragile; questa è solo la natura di internet.

Che ne dici di impostare socatcome [x]inetdservizio?

Si imposta xinetdper ascoltare in PORT-B e iniziare socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIOnon appena il lato B si collega.

xinetdpasserà il traffico in entrata dal lato B all'input standard di socat, catturerà l'output standard socate lo passerà al lato B.

Se B si disconnette, socatè possibile terminare il processo; xinetdne avvierà uno nuovo non appena B si connetterà nuovamente. Mentre B è disconnesso, A riceverà errori di "connessione rifiutata".

Una volta dovevo fare qualcosa di abbastanza simile su un vecchio sistema HP-UX.

Il mondo reale è disordinato.

Nel mondo reale a volte muoiono le connessioni TCP, questo può accadere ad esempio se viene riavviato un firewall con stato o NAT, se la connessione dura troppo a lungo senza traffico, se la connessione sottostante è inattiva per troppo tempo.

Inoltre a volte quando le connessioni muoiono non muoiono simmetricamente. Se una connessione che trasporta molti dati si interrompe, è probabile che il mittente noterà che è morto molto prima che il destinatario lo faccia. Questo ha un paio di effetti collaterali.

• Se la connessione viene avviata dal mittente al destinatario, è possibile che arrivi una nuova connessione mentre la connessione precedente è apparentemente ancora attiva.
• Se la connessione viene avviata dal destinatario al mittente, è possibile che si verifichi un ritardo sostanziale tra il mittente che rileva la connessione interrotta e il destinatario che rileva tale fatto e avvia una riconnessione.

Inoltre le connessioni TCP sono un flusso di byte, NON un flusso di messaggi, quindi quando la connessione si interrompe potresti ricevere un messaggio parziale.

Il risultato netto di questo mi porta a concludere che una soluzione solida richiede una comprensione del protocollo dell'applicazione in modo che la soluzione possa essere compresa.

1. Come giuntare i flussi quando arriva una nuova connessione.
2. Non lo è se i messaggi devono essere archiviati quando l'origine dati è connessa dal destinatario dei dati.
3. Se un meccanismo di riconoscimento end-to-end è appropriato per prevenire la perdita di messaggi.
4. Se è necessario un qualche tipo di meccanismo "ping" a livello di applicazione per accelerare il rilevamento di connessioni morte.