Какова лучшая архитектура для перехода на XMPP?

Ответ 1

Протокол шлюза XMPP, о котором вы слышали, скорее всего, будет связан с транспортом. Транспорт - это сервер, который подключается как к XMPP-серверу, так и к серверу, отличному от XMPP. Управляя транспортом, я могу использовать свой Jabber-клиент, чтобы поговорить с кем-то, используя, скажем, MSN Messenger.

Транспорт обычно соединяется один раз с удаленной сетью для каждого JID, который он видит в режиме онлайн. То есть, это ваш вариант 2 в обратном порядке. Это связано с тем, что между транспортом и сетью, отличной от XMPP, нет никакой особой взаимосвязи; транспорт просто действует как куча постоянных клиентов. Чтобы это сработало, клиенты XMPP должны сначала зарегистрироваться в транспорте, указав учетные данные для удаленной сети и разрешить транспорту просматривать их присутствие.

Единственная причина, по которой это может улучшить масштабирование, заключается в том, что для одной и той же удаленной сети может быть много транспортов. Например, мой Jabber-сервер может запустить транспорт в MSN, другой Jabber-сервер может запустить еще один и т.д., Каждый из которых предоставляет соединения для другого подмножества пользователей XMPP. Хотя это расширяет нагрузку на сторону Jabber, а балансировка нагрузки на вашей системе также может распространять нагрузку, она по-прежнему требует большого количества соединений между двумя системами.

В вашем случае, поскольку (я полагаю), сторона, не относящаяся к XMPP, взаимодействует, размещение интерфейса сервера XMPP на сервере, отличном от XMPP, вероятно, будет вашим лучшим выбором. Этот серверный интерфейс лучше всего подходит для управления отображением между JID XMPP и как этот JID будет отображаться в собственной сети, а не заставлять пользователей XMPP регистрироваться и т.д.

Если вы их не видели, вы можете найти их полезными:

• http://www.jabber.org/jabber-for-geeks/technology-overview
• http://www.xmpp.org/protocols/
• http://www.xmpp.org/extensions/

Надеюсь, что это поможет.

Ответ 2

Я тоже работаю над подобной системой.

Я иду с маршрутом шлюза/компонента. Я рассмотрел несколько вариантов и решил с этим.

Шлюз в основном является компонентом с конкретной целью подключения Jabber/XMPP к другой сети. Вам нужно будет построить большую часть вещей, которые вы считаете само собой разумеющимися при использовании XMPP в качестве клиента. Такие вещи, как управление списком.

Очень мало помогает онлайн по фактическому дизайну и построению компонента. Как и в предыдущем ответе, я обнаружил, что xmpp-протоколы/расширения могут помочь. Основные из них:

• Основной клиент 2008
• Основной сервер 2008
• Промежуточный клиент 2008
• Промежуточный сервер 2008

Чтение через них покажет вам, какие XEP вы должны будете обрабатывать. Игнорируйте материал, который будет обрабатываться сервером, к которому будет привязан ваш компонент.

Стыдно, что Djabberd имеет такую ​​плохую документацию, что их система "все является модулем" дала возможность поддержки сервера напрямую взаимодействовать с другой сетью. Я не сделал этого.

Ответ 3

В основном существуют два типа соединений с сервером (s2s). Первый называется либо шлюзом, либо транспортом, но они одно и то же. Это, вероятно, тот вид, который вы ищете. Я не мог найти конкретную документацию для сторонних сторон, но как XMPP думает о том, как делать переводы на устаревшие серверы, находится в http://xmpp.org/extensions/xep-0100.html. Второй вид действительно не объясняется ни в каких дополнительных XEP - это обычные соединения XMPP s2s. Посмотрите "Связь между серверами" в RFC 3920 или RFC 3920bis для последнего обновления проекта.

Поскольку у вас есть собственные пользователи и присутствие на вашем сервере, и это не XMPP, концепции не собираются полностью отображать модель XMPP. Здесь происходит работа транспорта. Вы должны сделать перевод с вашей модели на модель XMPP. Хотя это определенная работа, вы можете принять все решения.

Это подводит нас к одному из ключевых вариантов дизайна - вам нужно действительно решить, какие вещи вы собираетесь отображать на XMPP со своего сервиса, а какие нет. Эти описания функций и описания использования приводят к общей структуре. Например, это как транспорт для общения с службами чата AOL или MSN? Затем вам понадобится способ сопоставить их эквивалент реестров, присутствие и сохранить информацию о сеансе вместе с логинами и паролями от локальных пользователей на удаленном сервере. Это связано с тем, что вашему транспорту нужно будет притворяться, что это те пользователи, и им нужно будет войти в систему для них.

Или, может быть, вы просто мост s2s для другой шахматной игры на основе XMPP, поэтому вам не нужен логин на удаленном сервере и он может просто действовать аналогично серверу электронной почты и передавать информацию взад и вперед, (При обычных подключениях s2s единственным сеансом, который будет храниться, будет SASL-аутентификация, используемая с удаленным сервером, но на уровне пользователя s2s просто поддерживает соединение, а не сеанс входа в систему.)

Другими факторами являются масштабируемость и модульность на вашем конце. Вы пригвоздили некоторые проблемы масштабируемости. Взгляните на перенос нескольких транспортов, чтобы сбалансировать нагрузку. Для модульности см., Где вы хотите принять решение о том, что делать с каждым пакетом или действием. Например, как вы обрабатываете и отслеживаете данные подписки? Вы можете поместить его на свой транспорт, но тогда это упростит использование нескольких транспортов. Или, если вы сделаете это решение ближе к своему основному серверу, вы можете иметь более простой транспорт и использовать какой-то общий код, если вам нужно поговорить с другими службами, кроме XMPP. Компромисс - более сложный основной сервер с большим потенциалом уязвимости.

Ответ 4

Какую архитектуру вы должны использовать, зависит от системы, отличной от XMPP.

• Используете ли вы систему, отличную от XMPP? Если да, вы должны найти способ добавить к этой системе интерфейс XMPP-S2S, другими словами, заставить его действовать как сервер XMPP. AOL использует этот подход для AIM. К сожалению, они ограничили свой шлюз GoogleTalk.

• Вы не используете систему, отличную от XMPP, но у вас есть интерфейс федерации, который вы можете использовать - i. е. ваш шлюз может разговаривать с другой системой как с сервером и имеет собственное пространство имен. В этом случае вы можете создать шлюз, который будет действовать как федеративный сервер с обеих сторон. Я не знаю ни одного примера шлюза, который использует этот подход, но вы можете использовать его, если хотите построить общедоступный мост XMPP-to-SIP.

• Если система, отличная от XMPP, не дает вам интерфейс федерации, тогда у вас нет другого варианта, кроме как действовать как куча клиентов. В мире XMPP это называется "транспорт". Различия между транспортным и нормальным сервером в основном:

  • JID транспорта переносятся из другой системы (например, john.doe\[email protected] - действительно уродливые!)
  • Пользователи XMPP, которые хотят использовать транспорт, должны создать учетную запись в системе, отличной от XMPP, и предоставить учетные данные учетной записи этой учетной записи транспортной службе. Протокол XMPP даже имеет расширение протокола, которое позволяет пользователям XMPP выполнять регистрацию транспорта внутри диапазона.

Ответ 5

Другим подходом является работа с поставщиком XMPP-сервера. Большинство из них имеют внутренние API-интерфейсы, которые делают возможным внедрение инъекций из сторонних приложений. Например, Jabber XCP предоставляет API для этого, который очень прост в использовании.

(Раскрытие информации: я работаю в Jabber, Inc, компании за Jabber XCP)