Azure ロード バランサーでの (明らかな) 4 分間のアイドル接続タイムアウトを克服するには、接続がアイドル状態と見なされないように、パイプを介してクライアントにデータを時々送信する必要があるようです。
コントローラーは AsyncController としてセットアップされ、他のオブジェクトでいくつかの異なる非同期メソッドを起動します。これらはすべて IO Completion Ports を使用するようにセットアップされています。したがって、メソッドからすぐに戻り、完了パケットが処理されると、IIS は元の要求に戻り、View をレンダリングできるようにします。
この場合、定期的に数バイトを送信する方法はありますか? 「古典的な」状況では、メソッドを実行し、待機中にスピンして、非同期メソッドが完了するまで数秒ごとにデータを送信することもできました。ただし、この状況では、IIS スレッドは解放されて他の処理を行うことができるので、完了コールバックで IIS スレッドに接続し直します。何をすべきか？これは可能ですか？
あなたの特定のケースは Windows Azure 固有 (LB の 4 分間のタイムアウト) に関係していますが、問題は純粋な IIS/ASP.NET の作業です。とにかく、AsyncController/AsyncPage にいる間にクライアントに "ping-backs" を送信することはできないと思います。これが AsyncPages/Controllers の全体的な考え方です。IIS は、他の要求を処理するスレッドを持つソケットを脇に置きます。また、AsyncManager.OutstandingOperations.Decrement(); で OutstandingOperations をゼロにした場合にのみ元に戻ります。その後、クライアントに最終的な応答を送信するために制御が返されます。そして、あなたが応答を送信するポイントになると、後戻りはできません。
私はむしろ、誰かが応答を得るのに4分待つと考える理由のアーキテクチャアプローチについて議論したいと思います（アニメーションの「お待ちください」が良い場合でも）？この時期、いろいろなことが起こるかもしれません。ブラウザのクラッシュから、インターネットの中断、クライアントでの完全な電力損失/中断まで。実際の Azure を使用している場合は、Worker ロールのタスクをキュー (Azure Storage Queues または Service Bus Queues) 経由で送信してみませんか。非常に長時間実行されるタスクに対して目の前にある他のオプションは、SingalR と完全に AJAX 化されたソリューションを使用することです。長時間実行されている操作の状態を SignalR 経由で通信する場所。
コメントによるUPDATE 1
@knightpfhor によって提案されたアプローチに加えて、これはキューでも実現できます。リクエスタは、一意の ID を持つタスクを作成し、「タスク送信キュー」に送信します。次に、指定されたタスク ID を持つメッセージの「タスク完了」キューを「リッスン」(または定期的/不定期にポーリング) します。
いずれにせよ、長時間実行されるタスクの全期間にわたってクライアントを接続したままにする理由はわかりません。このような通信を切り離す方法はいくつかあります。