Comment configurer un proxy changeur de genre TCP persistant?

J'ai un fournisseur (A) qui souhaite nous envoyer des données via une connexion TCP entrante. Malheureusement, le service consommateur (B) ne peut pas recevoir de connexions TCP entrantes. De plus, il n'a pas d'adresse IP statique, une autre exigence.

Une façon de résoudre ce problème serait un service qui connecte le port TCP A entrant à un autre port TCP B, afin que le consommateur puisse établir une connexion sortante avec B.

Ce n'est pas un problème unique [1] [2] , et avec socat je peux faire quelque chose de très proche de ce que je veux:

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

Cependant, cela présente les problèmes suivants:

• Si B se déconnecte, il ne peut pas se reconnecter. Avec TCP4-LISTEN:PORT-B,reuseaddr,fork, il peut se connecter mais ne reçoit pas de données.
• B ne peut pas se connecter avant que A ait établi une connexion (surmontable)
• Une seule connexion peut être établie vers PORT-B(surmontable)

Existe-t-il un moyen d'ajuster la commande pour qu'elle devienne "permanente" et résistante aux pannes?

La question importante est de savoir comment A réagira à la perte de connexion ou au refus de connexion? Tout ce qui suppose qu'une seule connexion TCP restera en place pour toujours sera fragile; c'est juste la nature d'Internet.

Que diriez-vous de configurer le socatas a [x]inetdservice?

Vous devez définir xinetdpour écouter dans PORT-B et démarrer le socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIOdès que le côté B se connecte.

xinetdtransmettra le trafic entrant du côté B à l'entrée standard de socat, et interceptera la sortie standard de socatet le transmettra au côté B.

Si B se déconnecte, alors le socatprocessus peut se terminer; xinetddémarrera un nouveau dès que B se connectera à nouveau. Pendant que B est déconnecté, A recevra des erreurs de "connexion refusée".

J'ai déjà dû faire quelque chose de similaire sur un ancien système HP-UX.

Le monde réel est en désordre.

Dans le monde réel, les connexions TCP meurent parfois, cela peut se produire par exemple si un pare-feu dynamique ou NAT est redémarré, si la connexion va trop longtemps sans trafic, si la connexion sous-jacente est en panne trop longtemps.

De plus, parfois, lorsque les connexions meurent, elles ne meurent pas symétriquement. Si une connexion transportant beaucoup de données meurt, il est probable que l'expéditeur remarquera qu'elle est morte bien avant que le destinataire ne le fasse. Cela a quelques effets secondaires.

• Si la connexion est initiée de l'expéditeur au destinataire, une nouvelle connexion peut entrer alors que l'ancienne connexion est apparemment toujours en vie.
• Si la connexion est initiée du destinataire à l'expéditeur, il peut y avoir un délai substantiel entre l'expéditeur détectant que la connexion est rompue et le destinataire détectant ce fait et déclenchant une reconnexion.

De plus, les connexions TCP sont un flux d'octets, PAS un flux de messages, donc lorsque votre connexion s'éteint, vous pouvez recevoir un message partiel.

Le résultat net de cela m'amène à conclure qu'une solution robuste nécessite une compréhension du protocole d'application pour que votre solution puisse comprendre.

1. Comment épisser les flux lorsqu'une nouvelle connexion entre.
2. Le fait de savoir si les messages doivent être stockés ou non lorsque la source de données est connectée par le destinataire des données ne l'est pas.
3. Si un mécanisme d'acquittement de bout en bout est approprié pour éviter la perte de message.
4. Si une sorte de mécanisme "ping" au niveau de l'application est nécessaire pour accélérer la détection des connexions mortes.