Як налаштувати стійкий проксі-сервер TCP?

У мене є провайдер (A), який хоче надсилати нам дані через вхідне TCP-з'єднання. На жаль, споживацька послуга (B) не може отримувати вхідні TCP-з'єднання. Також у нього немає статичного IP, ще одна вимога.

Одним із способів вирішити це буде послуга, яка з'єднує вхідний порт TCP A до іншого порту TCP B, щоб споживач міг здійснити вихідне з'єднання з B.

Це не є унікальною проблемою [1] [2] , і за допомогою socat я можу зробити щось дуже близьке до того, що я хочу:

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

Однак це має такі проблеми:

• Якщо B від'єднається, він не може повторно підключитися. З TCP4-LISTEN:PORT-B,reuseaddr,fork, він може з'єднуватися, але не отримує даних.
• B не може підключитися до того, як A встановив з'єднання (переможна)
• Для встановлення PORT-B(переможного) можна встановити лише одне з'єднання

Чи є спосіб налаштувати команду таким чином, щоб вона стала "постійною" і стійкою до відмов?

Важливе питання полягає в тому, як A реагує на втрату зв’язку чи на відмову від з'єднання? Все, що тільки передбачає, що одне TCP-з'єднання назавжди залишатиметься, буде неміцним; ось лише природа Інтернету.

Як щодо налаштування служби socatяк [x]inetdслужби?

Ви б хотіли xinetdслухати в PORT-B і починати роботу, socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIOяк тільки підключається сторона B.

xinetdпередасть вхідний трафік з B-сторони на стандартний вхід socat, а також уловить стандартний вихід socatі передасть його на B-сторону.

Якщо B відключається, socatпроцес може бути дозволений закінчитися; xinetdпочне новий, як тільки B знову підключиться. Поки B відключений, A буде отримувати помилки "відмовлено у з'єднанні".

Колись мені довелося зробити щось подібне на старій системі HP-UX.

Реальний світ безладний.

У реальному світі іноді з’єднання TCP відмирають, це може статися, наприклад, якщо стаціонарний брандмауер або NAT перезавантажиться, якщо з'єднання буде занадто довгим без трафіку, якщо базове з'єднання буде занадто довгим.

Крім того, іноді, коли з'єднання гинуть, вони не вмирають симетрично. Якщо з'єднання, що містить багато даних, вмирає, то ймовірно, що відправник помітить, що він мертвий задовго до того, як одержувач це зробить. Це має пару побічних ефектів.

• Якщо з'єднання ініціюється від відправника до одержувача, то може з'явитися нове з'єднання, коли старе з'єднання, мабуть, ще живе.
• Якщо з'єднання ініціюється від одержувача до відправника, то може виникнути істотна затримка між тим, що відправник виявить, що з'єднання розірвано, і одержувач виявить цей факт і викликає повторне з'єднання.

Крім того, TCP-з'єднання - це потік байтів, а не потік повідомлень, тому коли ваше з'єднання вмирає, ви можете отримати часткове повідомлення.

Чистий результат цього приводить мене до висновку, що надійне рішення вимагає розуміння протоколу програми, щоб ваше рішення могло зрозуміти.

1. Як сплавити потоки, коли з'явиться нове з'єднання.
2. Незалежно від того, зберігати чи ні повідомлення, коли джерело даних підключено одержувачем даних, ні.
3. Чи підходить цілісний механізм підтвердження, щоб запобігти втраті повідомлень.
4. Чи потрібен якийсь механізм "ping" рівня програми, щоб прискорити виявлення мертвих з'єднань.