質問: handler.EndReceive(ar); // データを受信しているか if (BytesRead > 0) { /* 受信処理 */ // 再び受信待機をする. handler.BeginReceive(State.buffer, 0, StateObject.buffersize, 0, new AsyncCallback(ReadCallback), State); } // リードデータが0の場合切断検知 else { /* 切断 */ } } catch (Exception) { return; } } ``` 通信に関しては非同期ソケットと検索すると沢山出てくる BeginAccept、BeginReceiveなどを使っています。 アプリ起動と同時にAcceptを行うためのメソッドを別スレッドに任せて 完全に投げっぱなし状態にしています アプリからUDPのブロードキャストを使って特定のデータを送り それを受信した対象機器から接続要求が送られてくる仕組みです データを送る直前に事前に入力してもらっていた、アプリが動いているPCのIPを元に ソケットのバインドなどを行うようになっています アプリ側から接続要求は送りません 一度接続したら、明示的に切断の処理を走らせるまで 接続は維持したまま、受信したデータをその都度処理するために BeginReceviを繰り返し呼び出すようにしています 直したい点は ・接続要求スレッドの投げっぱなしを辞めたい 接続に失敗したり、IPを変更してやり直したりしたいため 無限ループによる投げっぱなしを辞めたいのですが 何をもってして、スレッドの終了とすればいいのか 送られてきた接続要求が全て処理し終えたらスレッド終了でもいいが いくつ要求が送られてくるかはわからないし、必ず一斉に送られてくるとも限らない タイムアウトを導入してもいいがどのように実装するか ・できたら受信処理の部分のBeginReceveの繰り返し呼び出すのもやめたい 理想は何かしらのデータが来たらその都度別スレッドを起こして処理をさせたい C/C++などのselectのようなものが理想 調べたら出来るそうですが、皆様ならどのように作るかなと思いました ・async/awaitを使った非同期のソケットを導入するべき? 非同期ソケットで検索すると9割がたBeginAcceptを使ったものが出てきますが async/awaitを使ったほうがコードの記述もすっきりするみたいです async/awaitの方が新しい技術だと思うのでこっちを使って実装するべきなのかどうか そもそもselectをつかった実装をする場合必然的にasync/awaitを使うことになるのか 自分の中でも聞きたいことがまとまっていなくてふわふわした感じになってしまって とても申し訳ないのですが 些細なことでも結構です。糞醜いソースだな!などの意見でも結構です 一人で考えることに限界を感じてきたので、何かしら思い当たることがあったら回答していただけるととても嬉しいです。 よろしくお願い致します。
回答: スレッドを使うなら、非同期ソケットを使うより、スレッドを立てて同期ソケットを使えばどうでしょう。 そのほうが受信完了、送信エラー検出など見通しが良くなりますぜ