¿Cómo configurar un proxy de cambio de género TCP persistente?

Tengo un proveedor (A) que quiere enviarnos datos a través de una conexión TCP entrante. Desafortunadamente, el servicio consumidor (B) no puede recibir conexiones TCP entrantes. Además no tiene una IP estática, otro requisito.

Una forma de resolver esto sería un servicio que conecte el puerto TCP A entrante a otro puerto TCP B, de modo que el consumidor pueda hacer una conexión saliente a B.

Este no es un problema único [1] [2] , y con socat puedo hacer algo muy parecido a lo que quiero:

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

Sin embargo, esto tiene los siguientes problemas:

• Si B se desconecta, no se puede volver a conectar. Con TCP4-LISTEN:PORT-B,reuseaddr,fork, se puede conectar pero no recibe datos.
• B no puede conectarse antes de que A haya establecido una conexión (superable)
• Solo se puede establecer una conexión para PORT-B(superable)

¿Hay alguna manera de ajustar el comando para que se convierta en "permanente" y resistente a fallas?

La pregunta importante es, ¿cómo reaccionará A ante la pérdida de conexión o ante la denegación de la conexión? Cualquier cosa que suponga que una única conexión TCP permanecerá activa para siempre será frágil; esa es solo la naturaleza de internet.

¿Qué hay de la creación de la socatcomo un [x]inetdservicio?

Debería configurar xinetdpara escuchar en PORT-B, y comenzar el socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIOtan pronto como se conecte el lado B.

xinetdpasará el tráfico entrante del lado B a la entrada estándar de socat, y capturará la salida estándar de socaty la pasará al lado B.

Si B se desconecta, socatse puede permitir que finalice el proceso; xinetdiniciará uno nuevo tan pronto como B se conecte nuevamente. Mientras B está desconectado, A recibirá errores de "conexión rechazada".

Una vez tuve que hacer algo bastante similar en un viejo sistema HP-UX.

El mundo real es desordenado.

En el mundo real, a veces las conexiones TCP mueren, esto puede suceder, por ejemplo, si se reinicia un firewall con estado o NAT, si la conexión dura demasiado sin tráfico, si la conexión subyacente está inactiva durante demasiado tiempo.

Además, a veces, cuando las conexiones mueren, no mueren simétricamente. Si una conexión que transporta muchos datos muere, es probable que el remitente se dé cuenta de que está inactiva mucho antes de que el destinatario lo haga. Esto tiene un par de efectos secundarios.

• Si la conexión se inicia de remitente a destinatario, entonces puede entrar una nueva conexión mientras que la conexión anterior aparentemente sigue viva.
• Si la conexión se inicia del destinatario al remitente, puede haber un retraso considerable entre el remitente que detecta que la conexión está interrumpida y el destinatario que detecta ese hecho y desencadena una reconexión.

Además, las conexiones TCP son una secuencia de bytes, NO una secuencia de mensajes, por lo que cuando su conexión falle, puede recibir un mensaje parcial.

El resultado neto de esto me lleva a concluir que una solución robusta requiere una comprensión del protocolo de aplicación para que su solución pueda entender.

1. Cómo empalmar las transmisiones cuando entra una nueva conexión.
2. Si los mensajes deben almacenarse o no cuando la fuente de datos está conectada por el destinatario de datos no lo está.
3. Si un mecanismo de reconocimiento de extremo a extremo es apropiado para evitar la pérdida de mensajes.
4. Si se necesita algún tipo de mecanismo de "ping" a nivel de aplicación para acelerar la detección de conexiones inactivas.