WPUCreateSocketHandle 関数 (ws2spi.h)

  • [アーティクル]

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

関連項目

WPUCloseSocketHandle

WPUCompleteOverlappedRequest

WPUModifyIFSHandle

WPUQuerySocketHandleContext

LPWSPRecv

LPWSPSend

WSPStartup