This document documents the current distribution model for multi-user chat and introduces a smart multi-user chat distribution strategy to cut down on traffic and load.
WARNING: This document has not yet been accepted for consideration or approved in any official manner by the Jabber Software Foundation, and this document must not be referred to as a Jabber Enhancement Proposal (JEP). If this document is accepted as a JEP by the Jabber Council, it will be published at <http://www.jabber.org/jeps/> and announced on the <standards-jig@jabber.org> mailing list.
Status:
ProtoJEP
Type:
Informational
Number: xxxx
Version: 0.0.1
Last Updated: 2006-05-15
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, JEP-0045
Supersedes: None
Superseded By: None
Short Name: Not yet assigned
Email:
lynX@jabber.getting.psyced.org
JID:
lynX@ve.symlynX.com
Email:
fippo@jabber.goes.symlynX.com
JID:
fippo@goodadvice.pages.de
This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
This document describes an optimized strategy of multi-user chat delivery called "Smart Unicast" to address the most pressing scalability issues involved with the currently used "Broad Unicast" strategy. The technique described is already successfully in use with the PSYC (Protocol for SYnchronous Conferencing) [1] as a part of its approach to multicasting. The new strategy integrates with the existing specification of Multi-User Chat [2].
Unicast -- Delivery of information to a single destination.
Broadcast -- Delivery of information to every destination on the network.
Multicast -- Delivery of information to a group of destinations simultaneously using the most efficient strategy to deliver messages over each link of the network only once and create clones when the links to the destinations split.
Local Context Receiver List -- List of local recipients subscribed to a 'Smart Unicast' or in future a 'Multicast' context. In this case the context is a groupchat. The list is computed in different ways depending on the context.
Dramatis Personae is the same as in Multi-User Chat [3], that is we have three witches on a server called "shakespeare.lit".
Further, we will assume that "macbeth.shakespeare.lit", the server where the multi-user chat room resides, is within reach of a direct server-to-server connection.
In the XMPP specification this strategy is referred to as 'Broadcast Model'. To avoid confusion with other meanings of the term 'broadcast' we prefer to speak of 'Broad Unicast'.
The MUC fans out a copy of each groupchat message to each occupant, even if more than one occupant happens to reside on the same receiving server.
The list of occupants used to this purpose is stored in the MUC.
Considering the Example of hag66 speaking to the darkcave, as presented in Multi-User Chat [4], the darkcave Service reflects the message back to the shakespeare.lit server as many times as there are occupants on that server.
hag66 ---------> darkcave MUC ---------> shakespeare.lit ----------> crone1
darkcave MUC ---------> shakespeare.lit ----------> wiccarocks
darkcave MUC ---------> shakespeare.lit ----------> hag66
Example 1. Occupant Sends a Message to All Occupants
<message
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>
Example 2. Service Reflects Message to All Occupants
<message
from='darkcave@macbeth.shakespeare.lit/thirdwitch'
to='crone1@shakespeare.lit/desktop'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>
<message
from='darkcave@macbeth.shakespeare.lit/thirdwitch'
to='wiccarocks@shakespeare.lit/laptop'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>
<message
from='darkcave@macbeth.shakespeare.lit/thirdwitch'
to='hag66@shakespeare.lit/pda'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>
The shakespeare.lit server will then forward each of these messages to the respective resources, 'desktop', 'laptop' and 'pda'.
This new approach however leaves it to the receiving server to sort out who is to receive the information, thus cutting down on the amount of transmitted data.
In the example, the darkcave MUC sends a single message to the shakespeare.lit server, which then distributes it, based upon the groupchat presence information that was exchanged beforehand.
hag66 ---------> darkcave MUC ---------> shakespeare.lit ----------> crone1
shakespeare.lit ----------> wiccarocks
shakespeare.lit ----------> hag66
Example 3. Occupant Sends a Message to All Occupants
<message
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>
Example 4. Service Reflects Message to Each Server
<message
from='darkcave@macbeth.shakespeare.lit/thirdwitch'
to='shakespeare.lit'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>
The shakespeare.lit server will then forward each of these messages to the local context receiver list.
The list is computed by paying attention to all successful Enter and Exit operations as defined in Multi-User Chat [5].
It MUST be ensured, that only users who have both requested entry to the context (Examples 15. and 17. "Jabber User Seeks to Enter a Room" for Groupchat 1.0 and Multi-User Chat) and have been granted such access (See example 19. "Service Sends New Occupant's Presence to All Occupants") are to be considered occupants and members of this list.
They MUST also be removed from the list when they request to leave the service (See example 34. "Occupant Exits a Room") or when the service removes a kicked occupant (Example 73. "Service Removes Kicked Occupant").
TODO: To activate this protocol, negotiation between the parties willing to optimize traffic is necessary. We are still in the process of discussing which kind of negotiation would be most appropriate, so this is as yet undefined. Should we opt for a new XMPP version, this would open up the possibility to leave out the 'to' element in the inter-server communication. Should a stream feature negotiation be desired instead, we will use the target domain name in a 'to' element. Therefore, in this example we have used 'shakespeare.lit'.
In a different JEP we have also proposed how to apply 'Smart Unicast' to presence. An extension JEP to both 'Smart Unicast' JEPs is in the making, which will extend the distribution strategy by real Multicast.
This JEP introduces no security considerations or concerns above and beyond those discussed in Multi-User Chat [6].
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [7].
This JEP requires no interaction with the Jabber Registrar [8].
1. PSYC (Protocol for SYnchronous Conferencing) is a distributed chat and messaging protocol which was designed with elaborate multicast distribution strategies in mind. For further information, see <http://www.psyc.eu>.
2. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.
3. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.
4. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.
5. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.
6. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.
7. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
8. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
First draft.
(ph / cvl)END