0

TCP ソケットを使用してあるプロセッサから別のプロセッサにファイルを転送する C++ アプリケーションがあります。アプリケーションは信頼性の低いネットワーク上で実行されるため、接続が失われたり回復したりしたときに転送を続行することが重要です。ACE を使用して、Windows または Linux でアプリケーションを実行できるようにしています。

現在、転送を開始して 2 つのプロセッサ間のネットワーク接続を切断した場合、約 20 秒以内に再接続すると、転送が回復し、すべて正常に動作します。20 秒以内に接続が再確立されない場合、接続がリセットされたことを示す Windows エラー 10054 が表示されます。その時点でソケットはなくなり、接続が再確立されると転送は再開されません。接続がいつタイムアウトになるかを制御できるように、それをオーバーライドする方法はありますか?

編集: これは Windows の問題のようです。Linux VM から Windows ボックスにファイルを送信しようとしました。転送中にネットワーク ケーブルを 5 分以上外しました。再接続すると、転送は中断したところから再開され、完了しました。

4

2 に答える 2

2

件名は、 How to preventではなくHow to handleと言うべきだと思いますよね？（コメントによると）その時点でファイル転送は一時停止状態になり、ユーザーもこれに気付くため、間違いなくこのエラーを取得したいと考えています。一時停止してユーザーに通知するには、エラーを取得する必要があります。

とにかく、あなたが言及した 20 秒は、おそらく OS/ルーターのタイムアウトによるものです。この数は大きく変動する可能性があり、決してそれに依存するべきではありません。パス上のすべてのボックスでタイムアウトを更新しようとすることもできますが、それは通常不可能であり、問​​題を実際に解決することはできません (設定したタイムアウトよりも長く接続を失う可能性があります)。

タイムアウトの影響を受けないソリューションを構築するには、生の接続の上に単純なプロトコルが必要であり、データ ストリームの特定のオフセットから再接続して転送を再開できるようにします。再送信ポイントに関する詳細を含むリクエストを送信するようにクライアントを変更できます。

ネットワークの信頼性が非常に低く、頻繁に壊れる場合は、UDP に切り替えることができます。到着するパケットもあれば、欠落するパケットもあります。ブロックを収集し、到着していないデータの一部の再送信を要求できます。適切なプロトコルの設計にもう少し時間を費やす必要があるかもしれませんが、そのソリューションは標準の TCP よりも優れている可能性があります。

于 2012-07-06T17:07:54.550 に答える
0

試してみることのできるいくつかのソケット オプションがあるかもしれませんが、適切な解決策はおそらく次のとおりです。

TCP の上に実装したプロトコルに再接続ロジックを組み込みます。

ネットワークケーブルをポートに接着したとしても、常にソケットの切断に対処する必要があります. したがって、ソケットが定期的に「再接続」を試みるようにし、この状況を処理することをプロトコルに認識させることに集中することもできます。(たとえば、N 秒ごとに再接続を試行し、最大タイムアウトになるまで毎回より長く待機する可能性があります)。そして、プロトコル固有の変更については、受信者が送信者にデータの転送を開始するポイントを指示する必要があるという前提から離れて作業します。Web ブラウザが http サーバーにファイル転送の再開方法を指示するのと似ています。

于 2012-07-07T04:39:59.920 に答える