Cookiesベース、共有サブドメインサイト用
1つのプロジェクトでこれがどのように可能かを共有したいと思います。 他のよく知られた方法を使用することの難しさは、プロジェクトが単一のドメイン名に結び付けられておらず、サブドメインのグリッドにローカライズされていたことでした。 つまり、プロジェクトサイトは第3レベルドメインに配置されていました。 この状況により、Same Origin Policeによる不便が生じました。
同期の種類とその目的は何ですか？
このような問題にまだ遭遇していない開発者は、おそらく興味深いでしょう。 さまざまな種類の「新しいメッセージ」、「新しい友達」などについてユーザーにオンラインで通知するWebサービス（ソーシャルネットワークなど）を想像してください。 MICEX自体の一部のDow JonesまたはGod forbidのオンラインインデックスを追跡するWebサービス。
そのようなプロジェクトのページから、一定の頻度で絶えず、サーバーへのリクエストが送信され、関連情報が取得されます。 さらに、一部のサービスは、クライアントとの継続的な接続を確立して、このクライアントをリアルタイムで暗いサーバー状態に維持します。
そのようなシステムの痛いところは、奇妙なことにブラウザから始まります。 「新しいタブで」ページを開くことをサポートするブラウザから。 さらに、プロジェクトがさまざまな種類の情報のために別個のタイプのページを持っている場合、さらに痛いです。 （しかし、それはまったく別の話です-デザインの歴史）。
実際、ユーザーが現在のページのリンクを常にクリックして「まあ、そこに与えられた成績」を確認するのは本当に不便です。
そして、ユーザーはナビゲーションのために最初に1つのタブを開き、次に評価を追跡するために2番目のタブを開き、次に新しいメッセージを追跡するために3番目のタブを開きます。 同時に開くタブの数は、「すべてを制御する」というユーザーの要望の量に直接依存します。
そのような各オープンページからの各クライアントからのリクエストを迅速に処理するには、いくつのサーバーが必要ですか？ 特に、リクエストが非同期で、ある程度の周期性がある場合。
このような問題を解決する必要性は、成長中のプロジェクトとウェブを飲み込む恐竜の両方が直面しています。
この問題を解決するには、少なくとも2つのオプションが適用されます。
-サーバーの容量を増やして、クライアント要求の処理時間を短縮します。 それを買う余裕のある人はわずかです。
-または、クライアント自身からの「理由」リクエスト。これは、どの観点から見ても、より最適かつ適切であると思われます。
なぜクッキー？
ローカルストレージ（およびその修正）の人気の高まりは、ドメイン制限規則（同じ発信元ポリシー）を課したという単純な理由に適していませんでした。 さらに、アクティブな（開いている）タブの状態を監視する必要がありました。これには、追加のリソースが必要です。 そして、これまでのところ、すべてのブラウザで機能するわけではありません。 同じ理由で、Flashには他のおいしい機能だけでなく、多くの希望もありませんでした。 ところで、良いアルゴリズムはここで説明されました 。
一般的に、何日も頭を壁にぶつけてオフィスデスクの端をかじった後、私は昔からのネイティブブラウザーメカニズムであるCookieを思い出しました。
作業スキーム
- ページ読み込み
現在のページのIDが決定され、独自のCookieが設定（チェック）されます。
間隔が設定され、その操作中にサーバーへの要求を実行する能力がチェックされます。
- インターバルトリガー
開いているページの最小IDを（Cookieから）取得します。
最小IDが自分のIDである場合、この場合のみ、データを受信するためにサーバーに要求が行われます。
それ以外の場合は、データの準備状況を確認し、必要に応じてそれらを取得します。
自己識別子を更新することを忘れないでください。
- サーバーリクエスト
サーバーの応答に通常のデータが含まれておらず、結果でCookieのみが設定されていることを除いて、ここでは特別なことは何も起こりません。 私の場合、それで十分でした。
タブに設定されたすべてのCookieをバイパスし、その値を「準備完了」として定義します。
- データ検索
最小IDが自身のIDと一致しない場合、独自のCookieの値がチェックされます。
その値が「準備完了」である場合-これは、データが安全に受信され、それを収集する必要があることを意味します。
データを取得し、現在のページのコンテキストで処理します。
特徴
- Cookieには優れた特性があります-追跡する必要のない寿命です-これはブラウザによって監視されます。
- タブを開くと、タブに「マーク」が付けられ、その識別子でCookieが設定されます。その識別子の有効期間は制限されています。
- Cookieは、自己更新の間隔をちょうど超える寿命で設定されます。
- サーバーの応答もcookieに設定されます。 私の場合、これは少量のデータであり、アクションの指標としてのみ機能します。
- タブがメインのタブでない場合、インターバル中にタブはCookieストレージからデータを収集して処理するだけです。
- 閉じられたタブはそのCookieのサポートを停止し、Cookieは安全に消滅します。 すべてのタブを開く前に管理がインターセプトします。
- データを含むCookieは、サーバーへの要求の前に破棄されます。 この時点で、他のすべてのタブで処理できます。
- 独自のCookieの安全性を確保するために、サーバーからのプロンプトが表示されたら、メインタブは独自のIDでCookieを再インストールします。
今、多くの実験の後、私は空想がこのメカニズムを最適化するために散歩できる場所があると思います。
このメソッドはメッセンジャー用に開発されたため、メッセンジャー自体のために、メッセンジャーが開いているタブを示すCookieも設定されました。 間隔がトリガーされると、メッセンジャーが開いているタブや、開いているタブなど、タブがチェックされました。 そして、彼女がメッセンジャーの「愛人」として現れなかったならば、彼女は彼女のケースでそれを閉じました。
メッセンジャーの状態は、ローカルストレージを使用して同期されました。 それがなければ、最後の状態を取得するためにサーバーにリクエストを行う方法、やることは何もありませんでした。
リンチ
欠点から始めましょう。
- 主な欠点は、Cookieのすべての荷物がサーバーへのリクエストごとに送信されることです。
- 2番目の重要な欠点は、サーバー応答のデータ量の制限です。 ご存じのとおり、1つのCookieの最大ボリュームは最大4 KBです（古代のIEでは、これは1つのドメインのすべてのCookieの合計ボリュームです）。 つまり、「私たちのコミュニケーション」は、アクションを示し、必要なパラメーターを渡すことに限定されます。
- このメカニズムは、1つのブラウザー内でのみ有効です。
- メソッドはまだ十分にデバッグされていません。 否定的なものと肯定的なものの両方の多くの詳細が明らかになると、コードは常に更新されますが、最適化が必要です。
利点：
- クロスプラットフォーム。 おそらくこれはかなり重要な肯定的な状況です。 Cookieメカニズムは、例外なくすべてのブラウザーでサポートされています。
- 「オン/オフ」タブの追跡に関する懸念は、ネイティブブラウザ機能に割り当てられます。 これにより、完全に標準化されていない他の機能とともに、一部のブラウザーで正常に動作しないbeforeUnload関数の問題が解消されました。
- 最小難易度。 このメソッドは、SharedObjectおよび他のWebWorkerを必要としません。 これらの機能をクロスブラウザで使用するアドオンも同様です。
説明されている方法の詳細については、アーカイブコピーをダウンロードできます 。
PS：アーカイブはドラフト版です。
PPS：ブラックジャック付きUPD 10/23/2014 バージョン2.0 ...