これは以前に出てきたもので、もう少し調査する価値があると思います。 部屋の作り方の質問と非常によく似ています。 これが私がどのように見えるかについての私の最初の亀裂です。 どう考えているか教えてください：

// The `channel` service method returns a string which is the key for a
// registered channel
app.service('messages').channel(message => `rooms/${message.room_id}`);
app.service('todos').channel(todo => `company/${todo.company_id}`);

app.on('connection', socket => {
  socket.on('authenticated', data => {
    // data.token
    // data.user
    const { token, user } = data;

    // For each user room add the socket to a channel
    user.rooms.forEach(roomId => app.channel(`rooms/${roomId}`, socket));
    // Register the socket in the `company/<company_id>` channel
    app.channel(`company/${company_id}`, socket);
  });
});

また、現在のイベントフィルタリングのパフォーマンスベンチマークにも興味があります。 これまでのところ、ボトルネックにはなっていませんが、チャネル/ルームを作成する簡単な方法があり、同時にパフォーマンスを向上させる可能性があるのは素晴らしいことです。

socket.ioにあるものと同様の部屋システムは良い考えだと思います。 便宜上、各ソケットには、自動的にサブスクライブする独自のシングルルーム（socket.io http://socket.io/docs/rooms-and-namespaces/のデフォルトルームなど）も必要です。これにより、簡単に送信できます。単一のクライアントへのイベント（ターゲットクライアントのデフォルトルームにブロードキャストすることによる）。
問題は、部屋のすべてのサブスクライバーにイベントをどのようにディスパッチするかです。 サーバーのすべてのソケット接続をループして目的の部屋に属するものをフィルタリングするのが何らかのフィルターである場合、現在のディスパッチャーと同じ効率の問題が発生します。 チャネル内のソケットのみをループする場合（=イベントをブロードキャストする必要のある部屋に参加した場合）は問題ありません。

これまでのところ、ディスパッチャの接続のループがボトルネックになっていないのは、大規模なアプリ（同時ユーザー数が5,000人を超える）でフェザーを使用したことがないからだと思います。 しかし、これは遅かれ早かれ来るでしょう（羽はまだ本当に新しいです）、そして私が私の本当に単純なベンチマークで見たものから、あなたが羽でスケーリングしようとすると、このforeachループが問題になることは間違いありません...
フェザーの単一サーバーノードと1kから100kのクライアント接続をエミュレートするいくつかのクライアントマシンを使用して「実際の」フェザーストレステストを行うことは、フェザーの現在の制限とボトルネックを確認することをお勧めします。 このストレステストのためにサーバーへの数千の同時接続を実行するスクリプトを実行するボランティアが必要な場合は、2台のコンピューター（2つの異なるインターネット接続がある）で喜んで実行できます。

はい。 チャネルは、接続中のクライアントの数を絞り込むことです。 たとえば、特定のユーザーチャネルを作成する場合、接続リストには1つのエントリしかありません。 Primusは部屋をサポートしていないので、もう少し一般的である必要があります（追加する必要がないと思うプラグインでのみ）。

これを前進させるには、次のことが必要だと思います。

• 特定のチャネル（または部屋と呼ばれるべき）に接続を固定し、データをブロードキャストするチャネルにサービスを絞り込む機能を追加できるチャネルAPIを把握（そして最終的には実装）します。
• プレーンなSocket.io、Feathers +イベントフィルターの実際のアプリベンチマーク、およびFeathers +チャネルのバージョンを作成して、改善点を確認します。

私の経験では、基本的なアプリ以上のサーバーあたり5kを超えるクライアント（実際のWebSocket接続を使用）は、プレーンなSocket.ioでも課題であり、64k以上ではサーバーが単純に不足するため物理的に不可能です。ポートの数（補足：Meteorは数百でチョークします）。 単一インスタンスでの100k以上の同時接続は非常にありそうもないので、おそらく心配する必要はありません（ここでいくつかのSocket.ioベンチマークを見つけまし

とは言うものの、チャンネル/ルームの機能を楽しみにしています。それは、パフォーマンスを向上させると同時に、はるかに簡単になるというよくある質問だからです。

64kの制限はよくある誤解です。 TCPポートは16ビット整数であるため、サーバーは65,536（216）を超えるTCPソケットを受け入れることができないと人々は考える傾向があります。
ただし、実際にはそうではありません。サーバーは実際にはすべてのソケットに対して1つのリスニングポートのみを使用し、IPアドレスと各クライアントのポートを使用してソケットを区別し
node.jsサーバーで100万を超える同時WebSocket接続を実現し、純粋なsocket.ioサーバーで100Kを超える接続を実現すると主張する人々の報告を見てきました。 したがって、少し調整するだけで、十分なCPUパワーとRAMがあれば、単一ノードsoket.io（feathers.js;））サーバーで約50kの同時Webソケット接続を実現できる可能性があります。
そうは言っても、socket.ioとPrimusの両方で機能するchannelsシステムをfeathers.jsに含めることは、私が思う本当のメリットです（パフォーマンスの向上から、現在フィルターを定義する必要がある多くの使用例もおそらく簡単になります） ）

やや現実的なアプリの再現可能なベンチマークで何が可能かを本当に知ることができると思います😄

次に、これらすべてに対する実際のAPI提案について説明します。

1）フックとしてのイベントとイベントフィルタリング

イベントの発行とフィルタリングをフックにリファクタリングします。 @ekryskiと私は前にこれについて話しました。 基本的に、フェザーフックはコアの依存関係になり、イベントの発行は常に最後に実行されるフックになります。

2）app.channel

文字列でキー設定された「チャネル」に接続（イベントエミッター）を固定できるapp.channelメソッドを追加します。

const updateChannels = (connection, user) => {
  // A channel just for this user
  app.channel(user._id, connection);

  // For each user room add the socket to the room channel
  user.rooms.forEach(roomId => app.channel(`rooms/${roomId}`, connection));

  // Register the socket in the `company/<company_id>` channel
  app.channel(`company/${user.company_id}`, connection);
};
app.on('connection', updateChannels);
app.on('login', updateChannels);

ここで注意が必要なのは、ユーザーが更新されたときにこれらのチャネルの同期を維持する方法を見つけることです。たとえば、接続したまま部屋を離れるなどです。

3）更新されたイベントフィルタリング

イベントフィルタリングを変更して、O(1) ）取得できます。

app.service('messages').filter('eventname', (message, connections, hook) => {
  // Just dispatch to one user
  if(message.isPrivate) {
    return connections.channel(message.receiver_id);
  }

  // The message room channel
  return connections.channel(`rooms/${message.room_id}`);

  // EVERYBODY!
  return connections;

  // Filter connections manually, e.g. if the connection user and message user are friends
  return connections.filter(connection => connection.user.friends.indexOf(message.user) !== -1);
});

これは重大な変更になります。 イベントフィルターは、ディスパッチされているデータを変更できなくなります。 イベントデータの変更は、 hook.resultまたはhook.dispatchいずれかを設定するフックで実行できます（＃376が関連しています）。 チェーンを使用して接続を絞り込むことは可能ですが、チャネルを返すと、常にそのチャネル内のすべての接続が返されます。 その間、イベントフィルターを必須にすることもできます。

私には良さそうです。
チャネルの同期を維持する方法について。 それを担当するのは開発者の責任だと思います。 自動であってはなりません（ユーザーが切断した場合を除きます。その場合、もちろん、ユーザーの接続は、それが含まれていた各チャネルから自動的に削除されます）。 したがって、ある種のapp.unchannel()関数がある場合は、それをサービスフックに呼び出すことができるはずです。 そうすれば、ユーザーがパッチやアップデートユーザーサービスなどから部屋を離れた場合、 app.unchannel( Rooms / $ {roomId} , connection)を呼び出して、部屋から接続を削除する必要があります（ s）彼が去った（または、「ユーザー」サービスを介して処理するのではなく、部屋がある場合は、部屋をサブスクライブ/サブスクライブ解除するために使用されるサービスでこの関数を直接呼び出すことができます）。

素晴らしいディスカッションの人たちと@ramsestomをキックオフしてくれてありがとう！ @daffl私はあなたがそこで提案したすべてに同意します💯そして@ramsestomこれが確実に進行するにつれてベンチマークを支援したいと思います。 個々のスタンドアロンサービスでまとめるリポジトリの例がいくつかあります。完了したら、それらのベンチマークを取得するのは素晴らしいことです。 😄

ここで注意が必要なのは、ユーザーが更新されたときにこれらのチャネルの同期を維持する方法を見つけることです。

同意します。 ここで大声で考えてみると、このチャネル管理はサービス/アプリのクラスター全体でどのように機能するのでしょうか。 それは何かを変えるつもりですか？

チャンネルをサポートするためにfeathers-syncを適応させる必要がありますか？ 私の予感はイエスです。

私の推測では、feathers-syncはチャネルをサポートするように適合させる必要がありますが、おそらくそれほど難しくはないでしょう。 実際、単一のイベントをすべてのアプリケーションインスタンスに伝播する代わりに、すべてのアプリインスタンスに（イベント+ chanel_ID）を伝播する必要があります（したがって、渡されたデータにchanel_IDパラメーターを追加するためにfeathers-syncを適応させるだけです。クラスタノード間）。
実際、シャネルは問題なくクラスターのノード間で分割できます。 ノードクラスター間で一貫したシャネルのラベル付けを維持し、このノードに接続された接続のみをノードクラスターに設定する必要があります（したがって、イベントが接続「c1」（=クライアント1から）をシャネル「A」に追加するように要求した場合、たとえば、接続c1を処理するクラスターノードのみが要求を満たし、他のノードはc1接続が接続されていないため、それを黙って無視します。
したがって、単一ノードアプリの接続c1、c2、c3、c4を含むチャネル「A」は、ノードn1の接続c1、c2を含むチャネル「A」およびノー​​ドn2の接続c3、c4を含むチャネル「A」になります。 次に、イベントをシャネルAに伝播する必要があることがわかっている限り、このシャネルのすべての接続が同じノードに接続されているか、複数のノードに分割されているかに違いはありません。

私は何かが足りないかもしれませんが、それはありますか？ フィルタは、そのサーバー上のすべての_connected_クライアントに対して実行されます。 同じアプリをスケーリングするだけの場合でも、すべての接続は正しいチャネルに配置され、イベントは一致する接続されたクライアントにのみディスパッチされます。

サービスイベント以外のものを同期する必要はないと思います。これはfeathers-syncがすでに行っていることです。

これは、fethers-syncが現在どのように機能しているかによって異なります。 リクエストサービスイベントを同期しますか、それともサービスイベントに応答しますか？ （data、params）を含むcreate()リクエストがある場合、すべてのアプリインスタンスに伝播される（そしてそれぞれで処理される）リクエストですか？ それとも、すべてのアプリディスパッチャーに伝達されるのは、このリクエスト（リクエストが処理された後にクライアントに返されるプロミス）の結果ですか？
私はそれが2番目のオプションだと思っていたでしょう（そうでなければ、たとえばデータベースのエントリを作成または更新するサービスリクエストの場合、すべてのアプリインスタンスがリクエストイベントを処理すると、各アプリインスタンスがそれを実行しようとするため、問題が発生します。 。）

私が理解したように、羽のパイプラインはこれです：

----------------------リクエストを受信するノードインスタンスでのみ実行されます
イベントのリクエスト
フックの前
サービス方法自体
フックの後
結果イベント
------------------ <-これは、この時点で、feathers-syncを使用してノード間で同期されます。
------------------各ノードインスタンスで実行
フィルタ
発車係

これがfeathers-syncと同期される結果イベントである場合は、おそらく変更する必要があります。 現在のフィルターの実装では、すべての接続を反復処理しているため、各ノードの各接続でフィルターを実行できます。 したがって、ディスパッチするイベント以外のものを提供する必要はありません。 ただし、チャネルがある場合は、選択した接続セットでイベントをディスパッチする必要があります。 （一部のテスト関数に基づいて）このセットを選択するためにフィルターを使用しなくなったため、イベントとともにチャネル情報を渡して、ノードのどの接続でイベントを発行する必要があるかを知る必要があります（ただし、このチャネル情報はもちろん、イベントオブジェクト自体のプロパティとして統合されます。この場合、現在行われているように「event」オブジェクトを渡し、ディスパッチャでイベントのこの「channel」プロパティを調べて、適切な接続で出力する必要があります。それはあなたがそれをどのように実装するかによります）。

これは、これに対して非常にまもなく実装されるものの現在の最終提案です。

用語

• チャネルは、任意の数の接続、場合によってはディスパッチするデータを保持するオブジェクトであり、通常は特定の名前で登録されます
• connectionは、双方向接続上のFeathers固有の情報オブジェクトであり、接続されたユーザーなどの情報が含まれています。 Socket.ioの現在の実装では、これはsocket.feathersなり、Primusの場合はsocket.request.feathers
• ディスパッチは、イベントやフックデータに基づいてチャネル（およびチャネルが送信する必要のあるデータ）を返す関数です。

チャネル

app.channels 、 app.channel(... names)

指定された名前の新しいチャネルを作成して返すか、複数のチャネルを1つに結合します

// A list of all channel names
app.channels

// A channel only for admins
app.channel('admins')

// A channel for message room with id 2
app.channel('rooms/2')

// A combined channel for admins and rooms/2
app.channel('admins', 'rooms/2');

// All channels
app.channel(app.channels)

参加/退会

.join(connection)と.leave(connection)をチャネルで呼び出して、接続をチャネルに参加させたり、チャネルから離脱したりできます。

// Join the admin channel
app.channel('admins').join(connection);

// Leave the admin channel
app.channel('admins').leave(connection);

// Leave a channel conditionally
app.channel('admins', 'rooms').leave(connection => connection.userId === user._id);

// Leave all room channels
const roomChannels = app.channels.filter(channel => channel.indexOf('room/') === 0);

app.channel(roomChannels).leave(connection);

// Leave all channels
app.channel(app.channels).leave(connection);

イベントディスパッチ

イベントフィルターは、イベントの送信先のチャネルを決定します。 複数のイベントフィルターを登録して、複数のチャネルにデータを送信できます。 接続が複数のチャネルにある場合、イベントは1回だけ送信されます（データが同じである場合、その方法を理解する必要がある場合があります）。

// Handle a certain event for all services
app.dispatch('eventname', (message, hook) => {
  // Just dispatch to one user
  if(message.isPrivate) {
    return app.channel(message.receiver_id);
  }

  // Returning falsy or nothing will do nothing
});

// Handle a certain event for a specific service
app.dispatch('servicename', 'eventname', (message, hook) => {
  // Just dispatch to one user
  if(message.isPrivate) {
    return app.channel(message.receiver_id);
  }

  // Returning falsy or nothing will do nothing
});

// Send to a certain room
app.dispatch('messages', 'eventname', (message, hook) => {
  return app.channel(`rooms/${message.roomId}`);
});

// EVERYONE
app.dispatch('messages', 'eventname', (message, hook) => {
  return app.channel(app.channels);
});

// Filter connections manually, e.g. if the connection user and message user are friends
// This works similar to the old event filters
app.dispatch('messages', 'eventname', (message, hook) => {
  return app.channel(app.channels).filter(connection => connection.user.friends.indexOf(message.user) !== -1);
});

注：カスタムイベントのhookオブジェクトには、 { service, app, path, event }が含まれます。

また、どのデータを使用して決定することもできます。

app.dispatch('messages', 'eventname', (message, hook) => {
  const modifiedMessage = cloneAndModify(message);

  return app.channel(`rooms/${message.roomId}`, `rooms/general`).send(modifiedMessage);
});

チャネルを最新の状態に保つ

ユーザーまたはログインステータスが変更されたときにチャネルを更新する方法の例：

匿名ユーザー

app.on('connection', connection => {
  app.channel('anonymous').join(connection);
});

app.on('login', (payload, meta) => {
  const connection = meta.connection;

  // Connection can be undefined e.g. when logging in via REST
  if(connection) {
    // Leave anonymous channel first
    app.channel('anonymous').leave(connection);

    // Get the user object and stick into channels
    app.service('users').get(payload.userId).then(user => {
      // A channel just for this user
      app.channel(`users/${user._id}`).join(connection);

      // Put user into the chat rooms they joined
      user.rooms.forEach(roomId => {
        app.channel(`rooms/${roomId}`).join(connection);
      });
    });
  }
});

ユーザーが変更されたとき

app.service('users').on('patched', user => {
  // Find all connections belonging to this user
  app.channel(app.channels).leave(connection => connection.user._id === user._id)

  // Re-add the user to their channels  
  // A channel just for this user
  app.channel(`users/${user._id}`).join(connection);

  // Put user into the chat rooms they joined
  user.rooms.forEach(roomId => {
    app.channel(`rooms/${roomId}`).join(connection);
  });
});

connectionオブジェクトはフックで利用できますか？ フックでチャネルメンバーシップを管理する方法が必要になります。 ソケット接続のフックオブジェクトにcontext.connectionを含める必要がありますか？

// Join the admin channel
app.channel('admins').join(connection);

// Leave the admin channel
app.channel('admins').leave(connection);

ソケットのconnectionオブジェクトは、サービスメソッド呼び出しparamsマージされるものです（ただし、同じオブジェクトではありません）。 フックで何のために接続する必要がありますか？

私が見ることができた1つのことは、メソッドを呼び出したユーザーにイベントを送信しない方が簡単になるということですが、私たちは常にそうしないようにアドバイスしてきました。

たとえば、ユーザーがチャットアプリで新しい部屋を作成する場合、チャネルを作成し、その部屋のチャネルへのユーザーの接続に参加するためのコードはどこにありますか？

それは良い質問です。 デフォルトでは、現在フィルターをロードおよび設定しているユーザーサービスセットアップファイルにいくつかのテンプレートを配置でき

接続データはparamsと同じであるため、フックでチャネルメンバーシップを実行できるようにするのは少し難しいかもしれませんが、フックでこれを実行するのは非常に自然なことのようです。

まだ説明していないもう1つのことは、フックでソケットイベントを発行できない理由です。 フックでapp.channel('admins').dispatch({...})できるといいですね。 なぜうまくいかないのかとおっしゃっていましたが、聞き取れませんでした。

フック内のチャネルメンバーシップの場合、解決策は、ユーザーがログインまたはログアウトするたびに、フェザーアプリのルートのどこかに{user_id => connection}の同期された辞書マップを保持することです。
このように、join（）とleave（）は、接続オブジェクトをフックに直接渡すことなく、map [params.user.id]を使用してフックの内部から呼び出すことができます。

アプリの任意の時点でカスタムイベント（サービスイベントだけでなく、基本的にカスタムデータを使用するカスタムイベント）をディスパッチする可能性については、 app.channel('admins').dispatch({data to dispatch})ようなことができると素晴らしいと思います。フック

まだ説明していないもう1つのことは、フックでソケットイベントを発行できない理由です。 フックでapp.channel（ 'admins'）。dispatch（{...}）ができると便利です。 なぜうまくいかないのかとおっしゃっていましたが、聞き取れませんでした。

同意しました。 これは、@ dafflでも少しあいまいです。 それができるようになりたいと思います。

たとえば、ユーザーがチャットアプリで新しい部屋を作成する場合、チャネルを作成し、その部屋のチャネルへのユーザーの接続に参加するためのコードはどこにありますか？

@ramsestomが提案したようなことをする必要があるかもしれません。 ソケットIDまたはそのソケットに接続されたエンティティID（つまりユーザー）のいずれかによってソケット接続を取得するための便利なメソッドが必要になるかもしれないと考えています。 実行可能ですが、複数のアプリインスタンスと多数のソケットが行き来する場合、これは少し厄介になり始める可能性があります。

しかし、 @ marshallswainのユースケースをカバーするためにこれについてもう少し考えたので、それは2つのAPI呼び出しではない可能性がありますか？

• チャネルを作成するための1つ
• もう1つは、チャネルに「参加」します

これについてもう少し考えてみてください。2つのAPI呼び出しは機能しますが、参加できるチャネルを知っている場合に限ります。 基本的に、ユーザーは自分自身をチャンネルに追加することしかできません。 チャンネルに別のユーザーを追加できるSlackのようなことをしたいのなら、それは不可能かもしれません...

その場合、2つの選択肢があると思います。

1. ユーザーがあなたの知らないチャンネルにあなたを追加します。 実際に追加されるのではなく、チャネルへの招待を受け取り、チャネルに「参加」することを確認します。 したがって、あなたはまだ自分自身を追加しています。

2. ユーザーが実際にあなたをチャンネル

雑草に少し入る...

このようなことは、 user id -> connectionマッピングがなくても、 @ dafflが提案した提案で思います。 これは、プレリリースを行い、これをいくつかのアプリの製品/ステージングに入れて、エッジケースがどこにあるかを確認するのが良い理由でもあります。

たぶん、マッピングなしでこれの最初のカットを行いますか？ どう思いますか？

同意しました。 これは、@ dafflでも少しあいまいです。 それができるようになりたいと思います。

@marshallswainと@ekryskiがそれについて言及したので。 フックで独自の（場合によっては別の）サービスにイベントを発行することは問題ないと思いますが、接続されたクライアントまたはチャネルにフックから直接データを送信することはでき

サービスはトランスポートに依存しない必要があると言うのと同じように、サービス自体（およびそのフック）は、実行中のサーバーに誰が接続しているかを心配する必要がないように、「接続を認識しない」必要があると思います。 私たちはまだサービスにapp.service('myservice').dispatchを介してフィルター/ディスパッチャーを登録しているので、それは完全には真実ではないことを理解していますが、少なくともそれはその特定の目的のためだけですが、フックは何でもできます。

たとえば、ユーザーがチャットアプリで新しい部屋を作成する場合、チャネルを作成し、その部屋のチャネルへのユーザーの接続に参加するためのコードはどこにありますか？

それは正確には何ではありません

app.service('users').on('patched', user => {
  // Leave all channels belonging to a user
  app.channel(app.channels).leave(connection => connection.user._id === user._id)

  // Re-add the user to their channels  
  // A channel just for this user
  app.channel(`users/${user._id}`).join(connection);

  // Put user into the chat rooms they joined
  user.rooms.forEach(roomId => {
    app.channel(`rooms/${roomId}`).join(connection);
  });
});

ユーザーが部屋に参加したときにpatched受け取ると仮定しますか？

@dafflうん、うまくいくだろう。 😄

@daffl @ekryski @marshallswain私はそのシナリオを正確に解決しましたが、動的フェザーサービスを使用するともっと簡単になるかもしれません。

クライアントの/ channel / nameのようなカスタム名前空間にカスタムメッセージサービスを登録するサービスを作成しました。同じ/ channel / nameサービスに接続するだけで、メッセージングが可能になります。

Todo

• / channel /：nameをリッスンするサーバー上にfeathersサービスを作成します
  
  
  
  • / channel /：nameにまだ登録されていない場合は、チャネルメッセージサービスを作成します
  
  
• / channel *メッセージをフィルタリングするinitフックでsocket.ioまたはprimusが使用されている場合は作成し、/ channel / nameサービスを再度作成します
• クライアントで/ channel / nameサービスを登録して使用するだけです

リアルタイムを使用するより大きな展開で、異なる部屋の異なるデバイスを接続するためにそれを使用するのに役立つことを願っています

これは、1秒あたり約1億のメッセージを簡単に処理する、kafkaデプロイメントのような異なるボックスにも後で各チャネル名を送信できることを知っているので、最も拡張性があります。

この問題は、クローズされた後、最近のアクティビティがないため、自動的にロックされています。 関連するバグについては、この問題へのリンクを含む新しい問題を開いてください。