[Standards-JIG] JEP-0060: Supporting Multiple Recipients (S2S) with Multiple SubIds

Bob Wyman bob at wyman.us
Sun Feb 19 00:48:39 UTC 2006


Pedro Melo wrote:
> Right now, if several users of server A subscribe to a topic
> on server B, the event notifications are sent multiple times via
> S2S between B and A.

	Thanks for reminding me of this issue. Since at PubSub we've been
putting off S2S implementation for a variety of other reasons, I've simply
forgotten this one. It is certainly a significant issue. At PubSub.com,
we've seen the requirement to deliver a single message to 10's of thousands
of users at the same time. Given that we don't support S2S at the moment, we
can handle this internally. However, the moment we support S2S, we'll have a
problem...
	This issue was discussed at some length when we at PubSub were first
putting together our support for JEP-0060. I can't remember if this
discussion was on the list or if it was just back-channel talk with the
Jabber.org folk... We were able to eliminate duplicate messages being sent
to a single user by using SHIM (JEP-0131) headers to list the multiple
subids that the message should be delivered to. However, we weren't able to
get anything done about a single message being sent to multiple users. Since
we didn't implement S2S it wasn't a critical, immediate problem. What I had
wanted was some way to send multiple sets of SHIM headers but we were told
at the time that SHIM couldn't be modified in this way.
	As Ralph Meijer points out, JEP-0033 gets us part of the way to what
we need but doesn't help us support subids. The problem is that JEP-0033 is
focused on the <message> element while SHIM is used to modify the <item>
element. Thus, any solution is going to require either a fairly drastic
change as a result of combining the "to" and "subid" information into a
single element or requiring repetition of data in the message.

	Using the current practice, we craft a single-recipient,
multiple-subid message in the following way:

<message to='sample_at_pubsub_dot_com at xmpp.pubsub.com' 
  from='pubsub-delivery at xmpp.pubsub.com' >
  <event xmlns='http://www.jabber.org/protocol/pubsub#event'>
    <items node='pubsub/topics/101'>
       <item id='6802'>
         <headers xmlns='http://jabber.org/protocol/shim'>
           <header name="subid">pubsub/subs/b11ea</header>
           <header name="subid">pubsub/subs/f001a</header>
           </headers>
         <pubsub-message xmlns="http://pubsub.com/xmlns">
         ...
         </pubsub-message>
      </item>
    </items>
  </event>
</message>

Using JEP-0033 we would write multi-recipient messages as follows: (But, we
lose subid support since subid's are specific to users and should not be
revealed to other users.)

<message to='multicast.xmpp.pubsub.com' 
  from='pubsub-delivery at xmpp.pubsub.com' >
  <addresses xmlns='http://jabber.org/protocol/address'>
       <address type='to' jid='addr1 at pubsub.com'/>
       <address type='to' jid='addr2 at pubsub.com' />
  </addresses>
  <event xmlns='http://www.jabber.org/protocol/pubsub#event'>
    <items node='pubsub/topics/101'>
       <item id='6802'>
         <pubsub-message xmlns="http://pubsub.com/xmlns">
         ...
         </pubsub-message>
      </item>
    </items>
  </event>
</message>

Clearly, there is no solution that allows these two different sets of
requirements (multiple users and multiple subids) to be supported without
adding semantics to any existing "multicast" service. We can't get code
reuse in this instance without losing backwards compatibility. Thus, if
we're going to support both types of duplicate removal, we're going to have
to define a new pubsub specific multicast capability. (i.e. feature). For
now, let's just assume it is: "http://jabber.org/protocol/pubsub#addresses"

Given that JEP-0060 already allows some "multicast" support via SHIM at the
<item> level and that we undoubtedly don't want to invalidate all existing
JEP-0060 services and clients, it makes sense to provide multiple recipient
support at the item level. We might construct multiple-recipient,
multiple-subid messages as follows:
 
<message to='multicast.xmpp.pubsub.com' 
  from='pubsub-delivery at xmpp.pubsub.com' >
  <event xmlns='http://www.jabber.org/protocol/pubsub#event'>
    <items node='pubsub/topics/101'>
       <item id='6802'>
         <addresses xmlns='http://jabber.org/protocol/pubsub#addresses'>
           <address type='to' jid='addr1 at pubsub.com'
             <headers xmlns='http://jabber.org/protocol/shim'>
               <header name="subid">pubsub/subs/b11ea</header>
               <header name="subid">pubsub/subs/f001a</header>
             </headers>
           />
           <address type='to' jid='addr2 at pubsub.com'
             <headers xmlns='http://jabber.org/protocol/shim'>
               <header name="subid">pubsub/subs/dead001</header>
             </headers>           
           />
         </addresses>
         <pubsub-message xmlns="http://pubsub.com/xmlns">
         ...
         </pubsub-message>
      </item>
    </items>
  </event>
</message>

The PubSub-aware multicasting service would need to be aware that addressing
information would be associated with the <item/> element contained within
<events> rather than in the <message/> element. The service would use the
data in the items to break the messages out and send them to users in the
form of the first example we have above. (i.e. the current support for
single-recipient, multi-subid messages).

Note: It would be very nice to incorporate the SHIM namespace into the
pubsub#addresses namespace so that we wouldn't have the waste the bytes
needed to repeat the SHIM namespace on each <headers/> element...

Have I missed something here? Is there a less convoluted way to address this
set of issues?

	bob wyman






More information about the Standards mailing list