Существует в основном два типа соединений между серверами (s2s). Первый называется шлюзом или транспортом, но это одно и то же. Это, вероятно, тот, который вы ищете. Я не смог найти конкретную документацию для сторон не-XMPP, но то, как XMPP думает о переводе на устаревшие серверы, находится на http://xmpp.org/extensions/xep-0100.html. Второй тип действительно не объясняется ни в каких дополнительных XEP - это обычные XMPP s2 соединения. Ищите «Связь между серверами» в RFC 3920 или RFC 3920bis для получения последнего чернового обновления.
Поскольку у вас есть собственные пользователи и ваше присутствие на вашем сервере, а это не XMPP, концепции не будут полностью отображаться в модель XMPP. Вот тут и начинается работа транспорта. Вы должны выполнить перевод из вашей модели в модель XMPP. Пока это какая-то работа, вы все равно принимаете все решения.
Что дает нам право на один из ключевых вариантов дизайна - вам нужно действительно решить, какие вещи вы будете отображать в XMPP из своего сервиса, а какие нет. Эти функции и описания вариантов использования будут определять общую структуру. Например, это как транспорт для общения со службами чата AOL или MSN? Затем вам потребуется способ сопоставить их списки, сведения о присутствии и хранить информацию о сеансе, а также логины и пароли от локальных пользователей на удаленном сервере. Это потому, что ваш транспорт должен притворяться этими пользователями и должен будет войти в систему для них.
Или, может быть, вы просто мост s2s для чужой шахматной игры на основе XMPP, поэтому вам не требуется вход на удаленный сервер, и вы можете просто действовать аналогично серверу электронной почты и передавать информацию туда и обратно , (При обычных соединениях s2s единственным сеансом, который будет сохранен, будет аутентификация SASL, используемая с удаленным сервером, но на уровне пользователя s2s просто поддерживает соединение, а не сеанс входа в систему.)
Другими факторами являются масштабируемость и модульность с вашей стороны. Вы добились некоторых проблем с масштабируемостью. Взгляните на использование нескольких транспортных средств, чтобы сбалансировать нагрузку. Для модульности посмотрите, где вы хотите принять решение о том, что делать с каждым пакетом или действием. Например, как вы обрабатываете и отслеживаете данные подписки? Вы можете поместить его в свой транспорт, но тогда это усложнит использование нескольких транспортов. Или, если вы примете это решение ближе к вашему главному серверу, вы можете использовать более простые транспорты и использовать некоторый общий код, если вам нужно общаться с сервисами, отличными от XMPP. Компромисс - более сложный главный сервер с большей вероятностью уязвимости.