0

NAT/ファイアウォールの背後に配置される可能性が高いサーバー アプリケーションをデプロイするつもりであり、NAT ポート マッピングを微調整するようユーザーに要求したくないとしましょう。つまり、サーバーへの接続は不可能ですが、私のアプリは本質的にサーバー アプリケーションです。つまり、URI ごとにオブジェクトを送り返します。

現在、サーバーから定期的に接続を開始して、どのリクエストに応答する必要があるかを確認することを考えています。ポート 80 経由で HTTP を使用し、事実上どこからでも NAT/ファイアウォールを介して機能する可能性があります。

問題は、特に HTTP を使用して、アプリケーション レベルでサーバーとして機能できるクライアントを実装するための標準的な考慮事項と一般的な方法があるかどうかです。特別な HTTP ヘッダーはありますか? デザインパターン?

たとえば、次のスキームについて考えています。

  • クライアント (私の論理サーバー) は、ダミーの HTTP 要求をサーバーに送信します。
  • サーバーは非標準ヘッダーX-Request-URI:、などX-Host:で応答しますX-If-Modified-Since:。つまり、この状況では標準ではないため、X-xxx にラップされた要求ヘッダーです。また、接続を維持するように要求します
  • クライアントは、要求されたオブジェクトを送信する POST 要求で応答します。ここでも、ラップされたヘッダーを使用します (例:X-Status:など)

このようなことを行うためのより「標準的な」方法がない限り、私のアプローチはもっともらしいと思いますか?

編集: redditで興味深い議論がここで行われました

4

1 に答える 1

0

私は似たようなことをしました。これは非常に一般的です。クライアントはサーバーへの接続を開始し、接続を維持します。セッションがシャットダウンされた場合、クライアントは再開します。セッションが開始されると、クライアントが開始したため、サーバーはクライアントに何でもプッシュできます。

于 2011-09-03T16:49:03.130 に答える