3 ms·

The problem with XMPPs pubsub is that they don't have a clever multicast strategy. All they it does unicast, twitter something to your 200 friends @ example.com

by bartman 19y ago

The problem with XMPPs pubsub is that they don't have a clever multicast strategy. All they it does unicast, twitter something to your 200 friends @ example.com? 200 unicast messages to example.com. (See http://www.xmpp.org/extensions/xep-0060.html http://www.xmpp.org/extensions/xep-0060.html 1.2.)

mickael 19y ago
That's not true. We have implemented multicast during the Google summer of Code (See for example of the related patch: https://support.process-one.net/browse/EJAB-329 https://support.process-one.net/browse/EJAB-329). It being test and optimised but works today if you apply the patch. It will be in ejabberd 2.1. It is implemented in the server for multiple things, including pubsub and multi-user chat.
- bartman 19y ago
  That's an improvement, however, after looking at it I must say that that's not multicast. This is multiple recipients for a message. You shouldn't need to address the recipients, presence already involves people subscribing to your "presence channel". Thus your homeserver should know how to distribute the efficiently - for example by multicast. XEP-0033 just adds redundancy.
  - foonamefoo 19y ago
    Multicast only works on either something as esoteric as the MBONE or on a local LAN/WAN. It isn't out there on the general internet, it requires too much state in the routers, so it never took off.
    - mickael 19y ago
      The original comment was not on transport level multicast, but on application level multicast. This is the one implement in ejabberd patches and thus works over Internet, not only LAN/WAN.
    - wallflower 19y ago
      Transport-level mcast requires special routers.. Ah! No wonder I couldn't get the MBone videoconferencing stuff to work with Trumpet Winsock, years ago
  - mickael 19y ago
    The server knows how to distribute the message to multiple recipient and does that by itself. The client has of course nothing to do. ejabberd does that automatically for presence, but also for Multi-user chat and pubsub.

by bartman 19y ago

mickael 19y ago

That's not true. We have implemented multicast during the Google summer of Code (See for example of the related patch: https://support.process-one.net/browse/EJAB-329 https://support.process-one.net/browse/EJAB-329). It being test and optimised but works today if you apply the patch. It will be in ejabberd 2.1. It is implemented in the server for multiple things, including pubsub and multi-user chat.

bartman 19y ago
That's an improvement, however, after looking at it I must say that that's not multicast. This is multiple recipients for a message. You shouldn't need to address the recipients, presence already involves people subscribing to your "presence channel". Thus your homeserver should know how to distribute the efficiently - for example by multicast. XEP-0033 just adds redundancy.
- foonamefoo 19y ago
  Multicast only works on either something as esoteric as the MBONE or on a local LAN/WAN. It isn't out there on the general internet, it requires too much state in the routers, so it never took off.
  - mickael 19y ago
    The original comment was not on transport level multicast, but on application level multicast. This is the one implement in ejabberd patches and thus works over Internet, not only LAN/WAN.
  - wallflower 19y ago
    Transport-level mcast requires special routers.. Ah! No wonder I couldn't get the MBone videoconferencing stuff to work with Trumpet Winsock, years ago
- mickael 19y ago
  The server knows how to distribute the message to multiple recipient and does that by itself. The client has of course nothing to do. ejabberd does that automatically for presence, but also for Multi-user chat and pubsub.