WPUCreateSocketHandle 関数 (ws2spi.h)

[アーティクル]
08/28/2023

WPUCreateSocketHandle 関数は、新しいソケットハンドルを作成します。

構文

SOCKET WPUCreateSocketHandle(
  [in]  DWORD     dwCatalogEntryId,
  [in]  DWORD_PTR dwContext,
  [out] LPINT     lpErrno
);

パラメーター

[in] dwCatalogEntryId

呼び出し元サービスプロバイダーを識別する記述子。

[in] dwContext

新しいソケットハンドルに関連付けるコンテキスト値。

[out] lpErrno

エラーコードへのポインター。

戻り値

エラーが発生しない場合、 WPUCreateSocketHandle は新しいソケットハンドルを返します。それ以外の場合は、INVALID_SOCKETを返し、 lpErrno で特定のエラーコードを使用できます。

エラーコード	意味
WSAENOBUFS	新しいソケットハンドルを作成するのに十分なバッファーがありません。

解説

WPUCreateSocketHandle 関数は、指定されたプロバイダーの新しいソケットハンドルを作成します。 WPUCreateSocketHandle によって作成されたハンドルは、真のファイルシステムハンドルと区別できません。これは 2 つの点で重要です。まず、Windows ソケット 2 アーキテクチャでは、ファイルシステム関数 ReadFile と WriteFile をそれぞれこのサービスプロバイダーの LPWSPRecv 関数と LPWSPSend 関数にリダイレクトします。次に、完了ポートをサポートするオペレーティングシステムでは、Windows Sockets 2 アーキテクチャでは、完了ポートをソケットハンドルに関連付け、それを使用して重複した I/O 完了を報告することがサポートされています。

**注** ReadFile と WriteFile をリダイレクトするメカニズムには、リダイレクターにアクセスするためのユーザーからカーネルへの移行が必要です。その後、カーネルからユーザーへの切り替えが行われ、[LPWSPRecv](nc-ws2spi-lpwsprecv.md) または [LPWSPSend](nc-ws2spi-lpwspsend.md) に移動します。戻り値の場合、これらの遷移は逆に再トレースされます。パフォーマンスが大幅に低下する可能性があります。 **WPUCreateSocketHandle** を使用してソケットハンドルを作成するサービスプロバイダーは、そのWSAProtocol_Info 構造でXP1_IFS_HANDLES設定しないでください。クライアントは、**ReadFile** と **WriteFile** の使用を回避するために、ガイダンスとしてXP1_IFS_HANDLESがないことを受け取る必要があります。

**注** **WPUCreateSocketHandle** で作成されたソケットハンドルで完了ポートメカニズムを使用する場合、特別なパフォーマンスの低下はありません。サービスプロバイダーは、WPUCompleteOverlappedRequest を使用して、完了ポートに関係する可能性がある重複する I/O 操作の完了を読み上げる必要があります。クライアントは、完了通知のために完了ポートを作成、関連付け、使用するために、オペレーティングシステム関数を自由に使用できます (たとえば、 CreateIoCompletionPort、 GetQueuedCompletionStatus、関連するオペレーティングシステムのドキュメントを参照)。完了ポートは、Windows ソケット 2 によって提供される他の非同期通知メカニズムと統合されていないことに注意してください。つまり、クライアントは複数のイベントと完了コールバックを含む複数待機を実行できますが、複数待機に完了ポートを含める定義済みの方法はありません。

**階層型サービスプロバイダーに関する考慮事項**

この手順は、レイヤードサービスプロバイダーにとって特に重要です。レイヤードサービスプロバイダーは、 WPUModifyIFSHandle ではなく、このプロシージャを使用して、クライアントに公開するソケットハンドルを作成できます。この手順を使用する利点は、ソケットに関係するすべての I/O 要求がこのサービスプロバイダーを経由することが保証されることです。これは、クライアントがソケットがファイルシステムハンドルであると想定し、ファイルシステム関数 ReadFile と WriteFile を呼び出す場合でも当てはまります (ただし、この想定ではパフォーマンスが低下します)。

すべての I/O がこのレイヤーを通過することは、実際の I/O 操作の前または後に I/O ストリームを処理する必要があるレイヤーの要件です。 WPUCreateSocketHandle を使用してソケットハンドルを作成し、WSPStartup の時点で適切なサービスプロバイダーインターフェイスプロシージャディスパッチテーブルを指定すると、レイヤーが各 I/O 操作の開始に関与できるようになります。クライアントが重複する I/O 操作を要求する場合、このサービスプロバイダーレイヤーは通常、I/O 完了通知のパスに入るように配置する必要があります。

これが正しい理由を確認するには、I/O 完了通知が重複する目的で、クライアントが完了ポートをソケットハンドルに関連付けた場合の動作を検討してください。ポートは、次のレイヤーのソケットハンドルではなく、このレイヤーによって公開されるソケットハンドルに関連付けられています。このレイヤーは、完了ポートが関連付けられているか、ポートが何であるかを判断する方法はありません。このレイヤーは、次のレイヤーの I/O 操作を呼び出すときに、次のレイヤーのソケットハンドルを使用します。次のレイヤーのソケットハンドルには、同じ完了ポートの関連付けはありません。クライアントの予想される完了ポート通知は、追加のヘルプなしでは発生しません。

階層化されたサービスプロバイダーがこれを処理する通常の方法は、次のレイヤーで I/O 操作を呼び出すときに、異なる重複する I/O 構造と異なる重複する I/O パラメーターを置き換える方法です。代替の重複した I/O 構造体は、クライアントの格納されている重複した構造体とパラメーターを参照します。次のレイヤーの呼び出しによって、コールバック通知が設定されます。コールバック通知が発生すると、このレイヤーは必要な任意の後処理を実行し、クライアントの代わりに格納されている重複する I/O 情報を取得し、代替構造体を破棄して、適切な完了通知をクライアントに転送します。

要件


サポートされている最小のクライアント	Windows 2000 Professional [デスクトップアプリのみ]
サポートされている最小のサーバー	Windows 2000 Server [デスクトップアプリのみ]
対象プラットフォーム	Windows
ヘッダー	ws2spi.h

次の方法で共有

WPUCreateSocketHandle 関数 (ws2spi.h)

構文

パラメーター

戻り値

解説

要件

関連項目

フィードバック

その他のリソース