ウィンドウ サーバー ソケットと Linux クライアント ソケットがあります。クライアントはサーバーに接続し、メッセージを送信します。その後、サーバーは外部実行可能ファイルを呼び出します。問題は、サーバーが利用できない場合、接続機能でクライアントがタイムアウトでブロックされていることです。しかし、私はそれを望んでいません。接続が確立されていない場合は、クライアント ソケットがすぐに閉じられることを願っています。
誰かアドバイスをくれませんか?
ウィンドウ サーバー ソケットと Linux クライアント ソケットがあります。クライアントはサーバーに接続し、メッセージを送信します。その後、サーバーは外部実行可能ファイルを呼び出します。問題は、サーバーが利用できない場合、接続機能でクライアントがタイムアウトでブロックされていることです。しかし、私はそれを望んでいません。接続が確立されていない場合は、クライアント ソケットがすぐに閉じられることを願っています。
誰かアドバイスをくれませんか?
警告: 疑似コードが先にあります。
出来るよ。しかし、それはあなたが望むほど簡単ではありません。async_connect()
ブロックしないようにするには、クライアントから使用する必要があります。deadline_timer
次に、適切と思われるタイムアウトに設定する必要もあります。ゼロでは機能しませんasync_connect()
。しばらく時間を与える必要があります。でも、1秒か2秒でいいと思います。
タイマー ハンドラーはcancel()
、ソケットですべての非同期操作を実行する必要があります (接続だけであることを確認する必要があります。必要に応じて、より多くのソケットを使用します)。
それによってソケットが閉じられないことに注意してください。理想的にはasync_connect
、渡された error_code が否定的な結果を示すときはいつでも、のハンドラーでそれを閉じます。たとえば、キャンセルされた場合、ハンドラーは OPERATION_ABORTED を error_code として呼び出されます。
もちろん、それのみをチェックする場合close()
は、タイマー ハンドラのソケットのcancel()
. async_connect
ただし、他の理由で失敗したときはいつでも、ソケットが開いたままになります。
あなたの質問から、async_connect()
成功以外のエラーコードを渡すたびにソケットを閉じたいと思います。また、SUCCESS は、ブール値として使用されたときに暗黙的に 0 に変換される唯一の error_code であるため、ハンドラーでそれを確認するのは簡単です。^^
deadline_timer
のハンドラーでをキャンセルasync_connect()
すること、およびタイマー ハンドラーがソケットを閉じる前に OPERATION_ABORTED で呼び出されていないことを確認することを忘れないでください。^^