Bagaimana cara mengatur proxy pengubah gender TCP yang persisten?

Saya memiliki penyedia (A) yang ingin mengirimkan data kepada kami melalui koneksi TCP yang masuk. Sayangnya layanan yang dikonsumsi (B) tidak dapat menerima koneksi TCP masuk. Juga tidak memiliki IP statis, persyaratan lain.

Salah satu cara untuk menyelesaikannya adalah layanan yang menghubungkan port TCP A yang masuk ke port TCP B lainnya, sehingga konsumen dapat membuat koneksi outbound ke B.

Ini bukan masalah unik [1] [2] , dan dengan socat saya dapat membuat sesuatu yang sangat dekat dengan apa yang saya inginkan:

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

Namun, ini memiliki masalah berikut:

• Jika B terputus, ia tidak dapat terhubung kembali. Dengan TCP4-LISTEN:PORT-B,reuseaddr,fork, itu dapat terhubung tetapi tidak menerima data.
• B tidak dapat terhubung sebelum A membuat koneksi (dapat diatasi)
• Hanya satu koneksi yang dapat dibuat PORT-B(dapat diatasi)

Apakah ada cara untuk menyesuaikan perintah sehingga menjadi "permament" dan tahan terhadap kegagalan?

Pertanyaan penting adalah, bagaimana reaksi A terhadap hilangnya koneksi, atau terhadap koneksi yang ditolak? Apa pun yang hanya mengasumsikan bahwa koneksi TCP tunggal akan tetap selamanya akan menjadi rapuh; itulah sifat dasar internet.

Bagaimana dengan pengaturan socatsebagai [x]inetdlayanan?

Anda akan mengatur xinetduntuk mendengarkan di PORT-B, dan memulai socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIOsegera setelah sisi-B terhubung.

xinetdakan melewati lalu lintas masuk dari sisi B ke input standar socat, dan menangkap output standar socatdan meneruskannya ke sisi B.

Jika B terputus, maka socatproses dapat dibiarkan berakhir; xinetdakan memulai yang baru segera setelah B terhubung kembali. Sementara B terputus, A akan mendapatkan kesalahan "koneksi ditolak".

Saya pernah harus melakukan sesuatu yang sangat mirip pada sistem HP-UX lama.

Dunia nyata itu berantakan.

Dalam dunia nyata kadang-kadang koneksi TCP mati, ini dapat terjadi misalnya jika firewall stateful atau NAT di-reboot, jika koneksi berjalan terlalu lama tanpa lalu lintas, jika koneksi yang mendasarinya turun terlalu lama.

Lebih jauh lagi kadang-kadang ketika koneksi mati mereka tidak mati secara simetris. Jika koneksi yang membawa banyak data mati, maka kemungkinan pengirim akan mengetahui bahwa itu sudah mati jauh sebelum penerima melakukannya. Ini memiliki beberapa efek samping.

• Jika koneksi dimulai dari pengirim ke penerima maka koneksi baru dapat masuk saat koneksi lama tampaknya masih hidup.
• Jika koneksi dimulai dari penerima ke pengirim maka mungkin ada penundaan yang substansial antara pengirim mendeteksi koneksi terputus dan penerima mendeteksi fakta itu dan memicu koneksi ulang.

Selanjutnya koneksi TCP adalah aliran byte, BUKAN aliran pesan, jadi ketika koneksi Anda mati, Anda mungkin menerima sebagian pesan.

Hasil bersih dari ini membuat saya menyimpulkan bahwa solusi yang kuat membutuhkan pemahaman tentang protokol aplikasi sehingga solusi Anda dapat mengerti.

1. Cara menyambung stream ketika koneksi baru masuk.
2. Apakah atau tidak pesan harus disimpan ketika sumber data dihubungkan oleh penerima data tidak.
3. Apakah mekanisme pengakuan ujung ke ujung sesuai untuk mencegah hilangnya pesan.
4. Apakah diperlukan semacam mekanisme "ping" tingkat aplikasi untuk mempercepat deteksi koneksi yang mati.