0

In the article http://www.cometdaily.com/2008/05/15/the-many-shades-of-bayeuxcometd-2/index.html the author describes:

Often with PubSub, developers feel the need to create a channel per user in order to deliver private messages to a client. For example, if a trading system wants to notify a user of completed trades, the temptation is to create a channel like /trades/a_user_id and each user will subscribe to their own channel. This approach works, but is not the most resource sensible way of solving this issue and requires security code to prevent unauthorized clients subscribing to other users channels.

What are the trade-offs between the service and broadcast channels to implement messages for a particular user? I understand the security aspect of the trade-off but what about resource overhead? I don't understand why there would be any more resources used with a broadcast channel than there would be for custom-routed service. If you could explain why one is better over the other for the use-case, rather than a blanket statement of being sensible or not, that could help lead me to a decision.

Chap
  • 2,776
  • 24
  • 31

1 Answers1

1

The article is pretty old, it refers to CometD 1 while we are now at CometD 3. You may want to check updates on the CometD website and read the CometD 3 documentation.

The concepts behind broadcast vs service channels are still valid for CometD 3.

The server allocates data structures for every channel is created, being it a broadcast or service channel.

In the example from that article, it is compared creating N broadcast channels - one for each user_id, versus creating just one service channel. The former solution is obviously using more resources on the server than the latter, and it's subject to sneak peeking (a client can guess a user_id and subscribe to that channel, thus receiving messages that are destined to other users).

For this particular case, all the application needs to do is to deliver a message to a specific client. For this use case, it is better to use a service channel because it uses less resources (the same server-side channel can be used for all users, without the risk that a user receives messages not destined to him/her) and it is more secure.

sbordet
  • 16,856
  • 1
  • 50
  • 45
  • Thank you for the quick reply! I understand the sneak peeking vulnerability and let's disregard that for a second. If we create the same routing behavior as the broadcast channel in the service channel, keeping track of subscribers for a user id, then wouldn't it be consuming the same amount of resources or is there more than just memory to consider? From looking at the code, it seems like there are a few pieces of overhead for a channel like sweeping and initialization. Does this greatly affect performance of the server when there are a lot of channels? – Chap Jun 14 '16 at 16:40
  • 1
    You _could_ use one service channel for each `user_id` but it would be unnecessary. Having said that, CometD has been tested to scale to tens of thousand of channels without problems - but you still want to pay attention to not waste resources if it's not necessary. The CometD APIs allow you to efficiently send messages to a single client, so it's very easy to write this kind of applications. – sbordet Jun 14 '16 at 20:57