>>787
レスありがとうございます。

同期recvのみでもデータ受信とタイムアウト発生を待機出来るような気がしますが、
やはりselectの方が良いのでしょうか？

sleepは>>789さんの仰る通り、Win32APIのSleepを呼び出しているようです。
接続が無い場合の無駄なループを減らすためか、100ms待機しています。
しかし>>787さんのselectを使う方が理にかなっていますね。
あと勘違いしてましたが、acceptの場合は非ブロッキングやselectのメリットって多いんですね。
というか同期acceptのみだと、停止（やるとすると無理矢理かWSACancelBlockingCallかな？）や受け入れ数制限とか出来ないんですね。

>>788
おかげさまで少しだけイメージが掴めてきたような気がします。
でもブロッキングに比べて、スレッドやメモリは節約できますが、コアが多くなるほど全体的なパフォーマンスが落ちるような気もします。
その場合はある程度接続が多くなると、スレッドを増やす感じなのかな？（イベントオブジェクトの場合は必然的にそういう実装になるようですが）

おもーい腰を上げて、もう少し他のP2Pあたりのソースコードでも読みつつ勉強しようと思います。。