長いポーリングを開始するクライアントは、サーバー上のメソッドをAsyncCallback呼び出し、サーバーが非同期でクライアントに戻るときに呼び出されるコールバックデリゲートを含むインスタンスを渡します。
これについての私の理解は限られていますが、BasicHttpWCFでは、AsyncCallbackパラメーターがシリアル化されてサーバーに送信され、サーバーが逆シリアル化してキャッシュし、最終的に呼び出してクライアントに「戻す」ように見えます。
まず、上記の説明は正しいですか？AsyncCallback次に、ネットワーク全体でクライアント上でどのように呼び出されますか？
接続は開いたままなので、サーバーは既存の接続を介して応答します。これには、応答にコールバックハンドラー名が含まれます。
クライアントはメッセージの形式を理解し、サーバー応答からのデータを使用して（コールバックハンドラーに基づいて）適切なローカルメソッドを呼び出すことができます。
私は通常ウィキペディアを引用したくないのですが、この場合、それは長いポーリングの悪い説明ではありません...
ロングポーリングは、従来のポーリング手法のバリエーションであり、サーバーからクライアントへの情報プッシュのエミュレーションを可能にします。長いポーリングでは、クライアントは通常のポーリングと同様の方法でサーバーに情報を要求します。ただし、サーバーにクライアントが利用できる情報がない場合、サーバーは空の応答を送信する代わりに、要求を保持し、いくつかの情報が利用可能になるのを待ちます。情報が利用可能になると（または適切なタイムアウトの後）、完全な応答がクライアントに送信されます。クライアントは通常、すぐにサーバーに情報を再要求するため、サーバーにはほとんどの場合、イベントに応答してデータを配信するために使用できる待機中の要求があります。Web / AJAXコンテキストでは、ロングポーリングはCometプログラミングとも呼ばれます。
AsyncCallbackます）これは、JSONPの動作方法（コールバック部分、長いポーリングではない）に似ていますが、これに精通している場合はどうでしょうか。基本的に、コールバックハンドルはサーバーにのみ渡されるため、応答とともに返送され、クライアントは正しいメソッドを呼び出すことができます。
意図されたメソッドのみが呼び出され、悪意のあるサーバーがクライアントコードで選択したメソッドを実行できないことを確認するために、内部で追加のチェックが行われています。
@Basicの答えはとても良いですが、一部の人にとっては理解しやすい説明を書きたいと思っています。
AsyncCallbackそのローカルクラスは、サーバーへの接続を確立し、渡されたものへの参照とともにその接続をオブジェクトに配置しますAsyncCallback、情報とともに呼び出されますしたがって、実際には、非同期部分である応答を待機しているフレームワーク（クライアント側）です。TCP接続とサーバー処理はすべて標準です（長いポーリングで何も返されない場合に応答するのを待つことを除いて）
これは、長いポーリング、画像のダウンロードなど、あらゆる言語での非同期Webリクエストの基本的なプロセスを説明する必要があります。