問題タブ [ddp]

分散 ddp クライアント用のパッケージを作成しています

基本的なルーチンは次のとおりです。

1. クライアント接続
2. 新しい場合は、Diffie–Hellman 鍵交換アルゴリズムを使用して独自の鍵と秘密をネゴシエートします
3. 次に、キーと暗号化されたパスワードでログインします

ユーザーは、指定された IP で検索することにより、クライアントを自分のアカウントに割り当てることができます

このようにして、自動クライアント登録が行われます。

私が解決したいのは、サーバー側でMeteor.userIdに似た機能を設計することです

step1: ddp クライアントのログイン (DH アルゴリズムをスキップ)

step2: ddp クライアントが他のメソッドを呼び出す

問題は Meteor.publish メソッドにあり、有効な ClientID を使用して現在のコンテキストですべてのサブスクリプションを簡単に再起動する方法はありますか? livedata パッケージの setUserId メソッドをたどることができますが、触れたくない多くの内部を使用します

これは動作する必要があります

または、私のタスクを達成するための他の方法はありますか? クライアントIDをコンテキストに保持したいだけなので、メソッド呼び出しごとに承認する必要はありません

この解決策は受け入れられません

いくつかの複雑なオブジェクト構造があり、Data::Printer を使用してそれらを調べています。オブジェクト (コンテナ) に別のオブジェクト (子) であるフィールドがある場合、子は DDP の出力にクラス名としてのみ表示されます。子の文字列化された値も見たいです。

例を見てみましょう：

出力：

ご覧のとおり、子は出力で区別できません。クラス名に加えて、またはクラス名の代わりに、その場所で文字列化を確認したいと思います。

Meteor の DDP プロトコルは、少量のデータ コレクションをサーバーからブラウザー ベースのクライアントに同期するのに非常に適しています。これにより、処理されるデータの量が本質的に制限されます。

ただし、あるサーバーから別のサーバーに大規模なコレクションを同期するために Meteor が使用されている状況や、ある MongoDB を別のサーバーと同期するために DDP プロトコル自体が使用されている状況を考えてみてください。

この場合、DDP はどのくらい効率的ですか (計算上)? 複数のクライアントにどの程度拡張できますか? パフォーマンスの制限は帯域幅のみですか、それとも DDP は一部の CPU バウンドにも影響しますか? 現在、DDP で合理的に同期できるデータの最大量はどれくらいですか? DDP はこれを行うための間違ったアプローチなのでしょうか (以下の参考文献を参照)。

いくつかの追加の考え:

• 私の知る限り、現在のバージョンの DDP は各クライアントのコレクション全体を追跡しているため、漸近的に非常に効率的とは言えません。
• スマート コレクションは、サーバーからクライアントへの同期コレクションのパフォーマンスを向上させるために作成されました。しかし、これが DDP を改善しているのか、それとも他の何かを改善しているのかは不明です。

以下も参照してください。

• 多くのリモート クライアントに MongoDB (または CouchDB) のリアルタイム レプリケーションを実装する方法
• 大量のデータを同期するための DDP とストレート MongoDB アクセス

編集：

これに関するいくつかの経験的な経験の後、答えは「あまり効率的ではない」と結論付けなければなりません。説明については、 https://stackoverflow.com/a/21835534/586086を参照してください。

Meteor 開発者との話し合いによると、この問題は将来的に DDP とパブリッシュ/サブスクライブ API のリビジョンで対処され、それによってマージ ボックスが削除され、クライアントがマージを処理することが示されました。これにより、サーバーの CPU/メモリが節約され、より大きなデータセットをネットワーク経由で送信できるようになります。

私はMeteorアプリAと別のアプリケーションを持っていますが、MeteorBを使用していませんが、アプリとデータ交換を行っていAます。ローカル ネットワークのマシンで起動Aすると正常に動作しますが、meteor.com ホスティングに展開すると動作しません。サーバーが応答しません。

B接続にはコードnew WebSocket("ws://" + host + ":3000/websocket")を使用します (DDP プロトコル)。しかし、ws を wss に変更すると、LAN 内のマシンでも動作しなくなり、応答しなくなります。

アプリのメインページをAブラウザーで開いたときに、次のような URL を使用していることがわかりました

wss://ddp--6774-{my host name}.meteor.com/sockjs/465/asf0b7da/websocket.

質問:

1. B接続にセキュアな WebSocket (wss) を使用するにはどうすればよいですか?

2. A{my host name}.meteor.com でホストされているものに接続するにはどうすればよいですか?

3. Aなどの固定 URL を使用してリクエストに強制的に返信するにはどうすればよいws://{my host name}.meteor.com:3000/websocketですか? wss の代わりに ws を使用するように強制するにはどうすればよいですか?

4. config.js または settings.js で何かを指定する必要がありますか?

5. DDP_DEFAULT_CONNECTION_URL、NODE_OPTIONS など、meteor.com ホスティングの環境変数を指定する方法はありますか?

少なくとも半分の時間、クライアントがMeteorアプリをロードするとき、サーバーに接続できません。

コンソールでこれを実行すると:

クライアントが接続、切断、再接続を繰り返していることがわかります。

Chrome の開発ツールで [ネットワーク] タブを開くと、約 1 ～ 2 秒ごとに別の WebSocket リクエストが行われていることがわかります。

何が原因でしょうか?

Chrome 拡張機能でddpおよびbrowserifyパッケージを使用して、ddp クライアント経由で Meteor アプリと通信しています。

ただし、接続をインスタンス化すると、次のエラーが発生します。

これは、new Websocket(uri='ws://localhost:3000/websocket', protocols={})

DDP (WebSocket) プロトコルで meteor.com でホストされているアプリにアクセスする方法で同様のエラーが表示されますか? 、しかし、ポートを443に変更する必要があった解決策は機能しませんでした.

誰にも回避策がありますか？

meteor 用の DDP クライアントを作成し、順序付きコレクションを実装しました。基本的に、 DDP 仕様の「追加」メソッドと「追加前」メソッドの両方を実装しましたが、それらを適切に解釈する方法に疑問があります。当初、サーバーは、注文されているかどうかに応じて、コレクションで「追加」または「追加前」のいずれかを (排他的に) 使用すると考えていました。しかし、順序付けられたコレクションと順序付けられていないコレクションがあるのは無意味に思えます。だからここに私の質問があります:「追加された」メッセージは、単に「addedBefore」 with (before == null)のエイリアスとして解釈されるべきですか?つまり、コレクションの最後に追加されますか?

また、cursor.observe(callbacks)で、次のコールバック関数added(document) または addedAt(document, atIndex, before) が見つかりました。両方の関数で通知されますが、パフォーマンス上の懸念から、それぞれにコールバックを設定しない方がよいでしょうか?