Windows ソケット : ブロッキング
このトピックおよび関連する次の 2 つのトピックでは、Windows ソケット プログラミングについて説明します。 ここではブロッキングについて説明します。 記事では、他の問題について説明します。Windows ソケット:バイトの順序付け と Windows ソケット:文字列の変換。
CAsyncSocket クラスを使うかこの派生クラスを使う場合は、上の処理を自分で管理する必要があります。 CSocket を使うかその派生クラスを使う場合は、MFC が管理します。
ブロッキング
ソケットは、"ブロッキング モード" と "非ブロッキング モード" のどちらにも設定できます。ブロッキング (つまり同期) モードでは、ソケットの関数はアクション完了まで戻りません。 関数が呼び出されたソケットは、呼び出しが戻るまで何もできません、つまりブロックされます。 たとえば、Receive メンバー関数の呼び出しは、送信側アプリケーションからの送信を待つため、完了するまでかなり時間がかかることがあります (CSocket を使用している場合、またはブロッキング モードで CAsyncSocket を使用している場合)。 CAsyncSocket オブジェクトが非ブロッキング モードの場合 (つまり非同期動作中) は、呼び出しは即座に戻り、現在のエラー コードとして WSAEWOULDBLOCK が返ります。GetLastError メンバー関数で取得できるこのエラー コードは、ブロッキング モードならばブロックすることになる、ということを示します。 (CSocket は WSAEWOULDBLOCK を返しません。 これは、クラスがブロッキングを管理するためです。
32 ビットおよび 64 ビットのオペレーティング システム (Windows 95 や Windows 98 など) と 16 ビットのオペレーティング システム (Windows 3.1 など) では、ソケットの動作が異なります。 32 ビットおよび 64 ビットのオペレーティング システムはプリエンプティブ マルチタスクを使用してマルチスレッドを提供しますが、16 ビット オペレーティング システムにはこれらの機能はありません。 32 ビットおよび 64 ビットのオペレーティング システムでは、ソケットを個別のワーカー スレッドに収容できます。 あるスレッドのソケットがブロックしても、アプリケーション内のほかの処理は妨害されず、ブロッキングに CPU タイムを費やすこともありません。 マルチスレッド プログラミングについては、「マルチスレッド」を参照してください。
注意
マルチスレッド アプリケーションでは、CSocket のブロッキング特性を使うと、ユーザー インターフェイスの応答性を損なわずに、プログラムのデザインを簡略化できます。 メイン スレッドでユーザーとの対話を処理し、代替スレッドで CSocket の処理を行うと、この 2 種類の論理動作を分離できます。 マルチスレッドでないアプリケーションでは、これらの 2 種類の処理が結合され、単一スレッドとして処理されます。この場合は通常、CAsyncSocket を使って通信要求を即時に処理するか、または CSocket::OnMessagePending をオーバーライドし、長時間の同期処理中にユーザー アクションを処理するようにします。
以降は、16 ビット オペレーティング システムを対象とするプログラマ向けの説明です。
通常、CAsyncSocket を使う場合は、ブロッキングを使わずに非同期動作にしてください。 非同期動作では、たとえば、Receive の呼び出し後にエラー コード WSAEWOULDBLOCK を受け取った時点から待機が始まり、再度読み取り可能になったことを通知する OnReceive メンバー関数が呼び出されるまで継続します。 非同期呼び出しは、ソケットの適切なコールバック通知関数 (OnReceive など) を呼び出すことで行われます。
Windows では、ブロッキング呼び出しは悪い手法と見なされます。 既定では、CAsyncSocket は非同期呼び出しをサポートするので、コールバック通知を使って自分でブロッキングを管理する必要があります。 一方、CSocket クラスは同期処理をサポートするので、Windows メッセージを送信し、ブロッキングの管理も行います。
ブロッキングの詳細については、Windows ソケットの仕様を参照してください。 上の関数についてを参照してくださいWindows ソケット:ソケット通知 と Windows ソケット:ソケット クラスからの派生。
詳細については、次のトピックを参照してください。