基本上有兩種類型的服務器的服務器(S2S)的連接。第一個要麼稱爲網關,要麼稱爲運輸工具,但它們是一回事。這可能是你正在尋找的那種。我找不到非XMPP方面的具體文檔,但XMPP認爲如何翻譯到舊版服務器的方式是http://xmpp.org/extensions/xep-0100.html。第二種類型在其他任何XEP中都沒有解釋 - 它是常規的XMPP s2s連接。在RFC 3920或RFC 3920bis中查找最新草案更新的「服務器到服務器通信」。
既然你有你的服務器上你自己的用戶和存在,它不是XMPP,這些概念都不會完全映射到XMPP模型。這就是運輸工作的地方。您必須從模型到XMPP模型進行翻譯。雖然這是一些工作,但您確實可以做出所有決定。
這給我們帶來正確的按鍵設計的選擇之一 - 你需要真正決定你要去哪些東西從你的服務映射到XMPP,你是不是有什麼。這些功能和用例描述將推動整體結構。例如,這就像一個交通工具可以與AOL或MSN聊天服務交談嗎?然後,您需要一種方法來映射其等值的名單,狀態,並將會話信息以及本地用戶的登錄名和密碼保存到遠程服務器。這是因爲您的交通工具需要僞裝成這些用戶,並且需要登錄才能使用。
或者,也許你只是通向別人基於XMPP的國際象棋遊戲的橋樑,所以你不需要在遠程服務器上登錄,並且可以採取與電子郵件服務器類似的行爲,並將信息傳回給向前。 (對於正常的s2s連接,唯一可以存儲的會話將是與遠程服務器一起使用的SASL認證,但在用戶級別,s2s僅維護連接,而不是登錄會話。)
其他因素包括可擴展性和模塊化。你注意到了一些可擴展性問題。看看放在多個運輸平衡負載。對於模塊化,請參閱您想要決定如何處理每個數據包或操作的位置。例如,您如何處理和跟蹤訂閱數據?你可以把它放在你的運輸工具上,但是這會使得使用多個運輸工具變得更困難。或者,如果您將此決策更靠近核心服務器,則您可以使用更簡單的傳輸方式,並在需要與XMPP以外的服務通信時使用一些通用代碼。權衡是一個更復雜的核心服務器,具有更大的漏洞潛力。