0

winsock を使用して tcp 通信を実装するアプリケーションがあるとします。ソケットごとにスレッドを作成し、その上でブロック受信します。データが到着したら、他のスレッド (リッスン スレッド) に通知したいと考えています。

これを実装する最良の方法は何だろうと思っていました：

  1. この設計から離れてノンブロッキング ソケットを使用すると、リッスン スレッドは絶えず反復してノンブロッキング受信を呼び出す必要があるため、スレッド セーフになります (ソケット用の余分なスレッドはありません)。

  2. 非同期プロシージャ コールを使用してリスニング スレッドに通知します。この場合も、apc がキューに入るのをアラート待機する必要があります。

  3. 各ソケットスレッドがメッセージを投稿するスレッドセーフなメッセージキューを実装し、リスナーは間隔ごとにそれを調べてそこからデータを取得します。

また、WSAAsyncSelect について読みましたが、これがメッセージをウィンドウに送信するために使用されていることがわかりました。他のスレッドに似たようなものはありませんか？（まあ、apcsは...だと思います）

ありがとう！

4

2 に答える 2

0

I/O 完了ポートを使用します。CreateIoCompletionPort()およびGetQueuedCompletionStatus()Win32 API の関数 (ファイル管理関数の下)を参照してください。この例では、ファイル ハンドルの代わりにソケット記述子が使用されます。

于 2013-04-14T06:56:30.840 に答える
0

ソケット API のメカニズム (リッスン、受け入れ、読み取り、書き込み) をアプリケーション ロジックとは別のレイヤーで抽象化することを常にお勧めします。着信接続中に作成される接続の状態をキャプチャするオブジェクトがあり、このオブジェクトで着信および発信トラフィックのバッファーを維持できます。これにより、ネットワーク インターフェイス レイヤーをアプリケーション コードから独立させることができます。これにより、アプリケーションの機能が基礎となる通信メカニズムから分離されるため、コードがよりクリーンになります。

ソケットのブロックまたは非ブロックの決定は、アプリケーションが達成する必要があるスケーラビリティのレベルによって異なります。アプリケーションが何百もの受信接続をサポートする必要がある場合、ソケットごとのスレッドのアプローチを採用することはあまり賢明ではありません。Io ポート ベースの実装を使用することをお勧めします。これにより、コードの複雑さが増してもアプリが非常にスケーラブルになります。ただし、任意の時点で数十の接続しか予測できない場合は、Win32 イベントまたはメッセージを使用する非同期ソケット モデルを使用できます。Win32 イベント ベースのアプローチは、同時ソケット数が 63 を超えると複数のスレッドを管理する必要があるため、特定の制限を超えて拡張することはできません (WaitForMultipleObjects は最大 64 ソケットしかサポートできないため)。ただし、Windows メッセージ ベースのメカニズムにはこの制限はありません。

MSDN で API ドキュメントWSAEventSelectと一緒に確認してください。WSAAsyncSelect

boost::asioパッケージも見てみるといいかもしれません。これは、ソケット API に対するきちんとした (少し複雑ですが) C++ の抽象化を提供します。

于 2013-12-11T07:25:00.630 に答える