moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

multiplexing details 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3302 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Philipp Hancke 2009-07-02 15:59:00 +00:00
parent 254c00ec1c
commit 0394bbc21d
1 changed files with 17 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
xep-0220.xml
View File

@ -433,13 +433,23 @@ send: <db:verify
</section2>
<section2 topic="Multiplexing" anchor='multiplex'>
<p>A single XML stream between Originating and Receiving Server can be used to multiplex stanzas for more than one domain pair. This usage is for historical reasons called "piggybacking". There are two variants of this:</p>
<ul>
<li>Origin Piggybacking, which employs different originating domains.</li>
<li>Destination Piggybacking, which employs different receiving domains.</li>
</ul>
<p>The Originating Server SHOULD NOT use Destination Piggybacking unless the Receiving Server has signalled support for dialback error handling via &lt;stream:features/&gt;. The Originating Server MAY then attempt to multiplex a domain 'B' on the stream to the Receiving Server that is already used for domain 'A' if the hostname and port resolution results in the same IP address and port combination.</p>
<p>The Originating Server MAY use Origin Piggybacking even if the Receiving Server has not signalled support for graceful dialback error handling.</p>
<p>A single XML stream between Originating and Receiving Server can be used to multiplex stanzas for more than one domain pair. This usage is for historical reasons called "PIGGYBACKING". One common motivation for this is virtual hosting, for which many domains are hosted on the same server. Another common motivation for such reuse is the existence of additional services associated with the Sender Domain but hosted at subdomains thereof. For example, both the "target.tld" and the "sender.tld" XMPP servers might host a groupchat service at "chat.target.tld" and "chat.sender.tld" respectively. Without multiplexing, many server-to-server connections would be necessary to exchange stanzas between those domains. With more domains, the number of connections might exceed the maximum number of connections allowed from a single IP address as explained in &xep0205;. Multiplexing reduces the number of connections to two.</p>
<p>Note: Because dialback operates on domain pairs, a total of eight dialback negotiations is necessary for a bidirectional exchange of stanzas between two sending domains and two target domains.</p>
<section3 topic="Multiplexing Sender Domains" anchor="senderpiggyback">
<p>In order to accept XML stanzas from rooms at "chat.sender.tld" intended for addresses at "target.tld", the "target.tld" domain will need to validate the "chat.sender.tld" domain (just as it already did for the "sender.tld" domain). Thus the Originating Server would now initiate a dialback negotiation with "target.tld" but specify the Sender Domain as "chat.sender.tld". Specifying different Sender Domains is called "SENDER PIGGYBACKING" and be MAY used without further negotation.</p>
</section3>
<section3 topic="Multiplexing Target Domains" anchor="targetpiggyback">
<!-- role switch -->
<p>Likewise, to send stanzas to rooms at "chat.target.tld" from addresses at "sender.tld", the Originating Server would initiate dialback negotiation with "chat.target.tld" on the same connection that may already be used to send stanzas from "sender.tld" to "target.tld", specifiying the Target Domain as "chat.target.tld". Specifiyng different target domains is called "TARGET PIGGYBACKING".</p>
<p>The Originating Server SHOULD NOT use Target Piggybacking unless the Receiving Server has signalled support for dialback error handling via &lt;stream:features/&gt;. The Originating Server MAY then attempt to multiplex a Sender Domain 'B' on the stream to the Receiving Server that is already used for Sender Domain 'A' if the hostname and port resolution results in the same IP address and port combination. For example:</p>
<example caption="DNS SRV Record for the sender.tld Zone"><![CDATA[
_xmpp-server._tcp.target.tld. 86400 IN SRV 10 0 5269 receiver.target.tld
_xmpp-server._tcp.chat.target.tld. 86400 IN SRV 10 0 5269 receiver.target.tld
receiver.target.tld. 86400 IN A 10.44.0.4
]]></example>
<!-- FIXME: what if there is such a SRV record for sender.tld with port 5269 but only an A record for chat.sender.tld? might be a good example -->
<p>Because DNS lookups for both "target.tld" and "chat.target.tld" resolve to the same IP address (10.44.0.4) and port (5269), "sender.tld" may initiate a dialback negotation from "sender.tld" to "chat.target.tld" over the same XML stream that is already used to send stanzas from "sender.tld" to "target.tld".</p>
</section3>
</section2>
</section1>