Home

Евгений Храмцов's Journal

(Latest 13 entries) (Calendar) (Friends) (User info)

Saturday, January 6, 2007

1:46PM - Jabber 2006

Решил вспомнить интересные (на мой взгляд) моменты в мире Jabber в ушедшем году.

События

04.01.2006 Jabber.Ru переехал на серверы Яндекса.
Это событие знаменательно тем, что породило массу слухов об отношении Яндекса к XMPP: появление официального Jabber-сервиса от Яндекса не предсказывал только ленивый.

17.01.2006 S2S от Google.
Google сдержал обещание и, не смотря на заверения скептиков, анонсировал открытие s2s-xmpp. Впрочем, весь скептицизм сдулся уже после того, как появились DNS SRV записи для s2s. Если верить заявлениям разработчика Google, Jabber был выбран ими из-за большого community, а также из-за более простой реализации по сравнению с SIP. Сервер написан на Java с использованием NIO и работает в JVM 1.5 на Linux'е.

13.02.2006 Запуск транспорта для Агента Mail.ru.
На Jabber.Ru был запущен очередной транспорт в проприетарную IM-сеть. Пользователи, оставшиеся за границами интересов компании Mail.Ru, получили возможность общения с целевой аудиторией "национального портала".

16.02.2006 Wildfire: полная поддержка XMPP.
Компания JiveSoftware заявила о полной совместимости с XMPP 1.0 в Wildfire. Таким образом, Wildfire стал вторым XMPP-1.0 сервером после ejabberd.

26.02.2006 Jabber.org сменил jabberd 1.4 на ejabberd 1.0.0.
Крупнейший публичный Jabber-сервис решил мигрировать на ejabberd. После миграции падать он меньше не стал из-за ограничений Erlang'а на 32-битной архитектуре, а вот проблемы с s2s исчезли.

07.07.2006 ЖЖаббер.
Brad Fitzpatrick запустил Jabber-сервис. Для тех кто следил за развитием событий
это не было большим сюрпризом, так как до этого события Brad занимался разработкой Jabber-сервера. Сервер называется djabberd, написан он на Perl'е и глючит его нипадеццки :). Позднее в качестве официального клиента был рекоммендован двухголовый (XMPP+SIP) клиент от Gizmo Project.

К сожалению, в ушедшем году были не только радостные события. 27-го апреля 2006-го года тяжёлая болезнь забрала жизнь Питера Милларда (Peter G. Millard) - автора Exodus'а, разработчика серии стандартов и администратора Jabber.org. В октябре 2006-го ему бы исполнилось 35 лет.

Тенденции

    Можно с уверенностью сказать, что 2006-й год был годом XMPP 1.0 Compliance. Практически во всех популярных серверах и клиентах реализована полная поддержка XMPP 1.0. Также очень порадовал тот факт, что крупные игроки рынка (в числе которых Google, Six Apart, IBM и Stalker Software) сделали шаг в сторону совместимости IM-сетей.
    Основными направлениями в развитии стандарта в прошедшем году были Jingle и PEP. Полноценных реализаций этих технологий так и не появилось, поэтому есть основания полагать, что они появятся в этом году.
    В качестве прорыва 2006-го года стоит отметить отечественный проект Bombus - XMPP-клиент для мобильных платформ J2ME. Мидлет продолжает набирать функциональность семимильными шагами и обрёл огромное число пользователей. В данный момент его распространённость ограничивается только отсутствием англоязычного сайта.

(5 comments | comment on this)

Thursday, December 7, 2006

7:54PM - IBM разродился Jabber'ом

Вчера компания IBM объявила о поддержке xmpp-s2s в Lotus Sametime Gateway 7.5. Таким образом, к XMPP примкнул (хотя бы на уровне s2s) ещё один крупный монстр, что не может не радовать :) Если вы прётесь от проприетарщины и хотите функциональность LCS, то, возможно, имеет смысл влепить у себя этот Lotus Sametime - теперь Jabber-комьюнити это стерпит :)

(1 comment | comment on this)

Sunday, September 24, 2006

2:34PM - S2S proxying in ejabberd

It is very important for companies with a huge internal infrastructure of XMPP servers to prevent direct S2S connections to this servers. However, in some cases there may be a need to "publish" XMPP addresses of employees of internal departments. In this cases some kind of "proxying" may be very usefull. This method is very popular in other protocols such as HTTP (proxies) or SMTP (relays). So, I think it is a good idea to implement S2S-proxying support in ejabberd. The typical scheme of S2S-proxying is shown in the figure below.

s2s_proxy

Recently I wrote a patch for ejabberd which makes it possible to act ejabberd as an S2S-proxy server or an S2S-proxy client. Here I want to describe briefly how to configure it.
According to the scheme, server corp.org acts as an S2S-proxy server. Servers a.corp.org and b.corp.org act as an S2S-proxy clients. First of all, we need to configure mod_s2s_proxy module on the corp.org server:

{modules, [
  ...
  {mod_s2s_proxy, [{hosts, ["a.corp.org", "b.corp.org"]}]},
  ...
]}.

Then we must to define global s2s_hub option on our S2S-clients. But we don't want to relay internal s2s connections via the proxy server. Hence, we need to create ACL with definitions of target domains which must be proxied:

{acl, local_domains, {server_glob, "*.corp.org"}}.
...
{access, via_proxy, [{deny, local_domains}, {allow, all}]}.

Then we just add this string to the global section of the config file:

{s2s_hub, [{host, "corp.org"}, {access, via_proxy}]}.

That's all :)

(2 comments | comment on this)

Tuesday, September 12, 2006

6:08PM - Udaff.com с нами

Сегодня proforg анонсировал запуск jabber-сервера. Регистрация свободная, интегрированна с соответсвующими email'ами. Сервис позиционируется как замена ICQ, что отражено в анонсе :) В качестве сервера используется ejabberd c двумя виртуальными доменами: udaff.com и maloletka.ru.

(2 comments | comment on this)

Monday, August 21, 2006

8:55AM - ХEP от XSF

Peter Saint-Andre решил таки переименовать Jabber в XMPP во всех документах. Мотивирует он это тем, что проприетарщикам, таким как Jive Software или Google, не нравится слово Jabber и они используют термин XMPP. Тем не менее, Peter не призывает хоронить слово Jabber. Просто для XMPP оно будет иметь тот же смысл, что и Web для HTTP. Например, Jabber-сообщество - Web-сообщество, Jabber-приложение - Web-приложение. При обсуждении этой трансформации в мейл-листе всем, в общем-то, было фиолетово, кроме halr9000, который сказал, что XMPP является не очень "дружелюбным" термином. Таким образом мы получаем новые названия: Jabber Council -> XMPP Council, jabber.org -> xmpp.org (для протоколов) и JEP -> ... XEP :) Так что теперь вместо джепов будем изучать херы. А хули делать :)

(3 comments | comment on this)

Sunday, August 13, 2006

3:09PM - XMPP Relay. Зло или необходимость?

Многие из нас, а в особенности администраторы SMTP-серверов, знакомы с понятием "релеинга". Многие админы его ненавидят, ибо по их мнению он представляет собой воплощение всех мыслимых зол. С моей точки зрения такое мнение однобоко и догматично. Есть некоторые ситуации, в которых релеинг полезен. Администраторы огромных корпоративных сетей прекрасно об этом знают и вполне успешно используют возможности релеинга в почтовой инфраструктуре. Типичная схема приведена ниже.

s2s-relay

Релеинг позволяет разделить обязанности между администраторами разных отделений, снять нагрузку на каналы связи (особенно если филиалы организации используют дорогие/ненадёжные/медленные WAN-соединения) и, конечно же, не нарушить принципы корпоративной сетевой защиты.
Затеял я этот разговор по нескольким причинам: во-первых, я сам являюсь счастливым обладателем такой сети, а, во-вторых, я часто вижу на форумах Jabber-серверов просьбы реализации релеинга.
Итак, с SMTP всё понятно - любой современный SMTP-сервер позволяет релеить сообщения "доверенных" узлов сети. С XMPP/Jabber немного хуже :) Всё портит одна строчка в RFC 3920:

"The 'from' attribute SHOULD be used only in the XML stream header from the receiving entity to the initiating entity, and MUST be set to a hostname serviced by the receiving entity that is granting access to the initiating entity."

Примерно то же самое относится и к заголовку "to" XMPP-пакета. Без нарушения RFC обойти это ограничение можно путём расширения кишков пакета с помощью нового JEP'а. Но это приведёт к дикому оверхеду при разборе пакета сервером, да и реализация не очень проста и, сорее всего, потребует некоторого рефакторинга.
Мне больше всего представляется другой путь - нарушение RFC :) Да-да, именно нарушение. Какое мне дело до догматиков, которые писали этот RFC и, тем самым, ограничили сферу XMPP публичными серверами. Ведь "granting access" можно проверить другими способами, например, записями в конфигурационном файле.

(1 comment | comment on this)

Thursday, August 3, 2006

3:14PM - XMPP URI. Теперь можно

Ну наконец-то блин. IETF очухался и принял пропихиваемый на протяжении около двух лет стандарт использования XMPP IRIs/URIs. Так что теперь использование ссылок вида xmpp:john@jabber.org вполне законно и безопасно :)

(1 comment | comment on this)

9:10AM - Python достал

Python продолжает меня неприятно удивлять своим менеджером памяти. После вчерашнего очередного падения DNS-балансера на mrim.mail.ru, Mrim опять начал пожирать память. Замечена некоторая особенность: на траснпорте в течении несколько часов висят соединения в состоянии socket.connect(). Почему Python не закрывает эти дохлые сокеты - мне неизвестно, но при этом начинает утекать куда-то память. Самое интересное, что при моих стресс-тестах (для них был специально написан  простенький MRA-сервер на Erlang'е) ничего не утекает даже на реконнектах 1k юзеров, а на mrim.jabber.ru сейчас их около 500 max. В общем это последняя моя серверная поделка на питоне. Полностью переключаюсь на эрланг :)

(1 comment | comment on this)

8:50AM - Потестируем?

Я наконец написал модуль ejabberd'а для работы с LDAP shared roster. Что-то вроде патчей лежит здесь. Шаблоны пока не реализованы - это будет сделано позже, после того как я точно удостоверюсь, что модуль работает со всеми LDAP-серверами (включая Active Directory, Lotus Domino и тд) и имеет достаточно гибкую систему настройки LDAP-атрибутов. Всех желающий прошу потестировать (желательно тестирование на LDAP-серверах, отличных от OpenLDAP). В случае возникновения проблем обращайтесь ко мне. Скорость добавления патча в основую ветку прямо пропорциональна активности тестирования :)

(2 comments | comment on this)

Friday, July 28, 2006

6:52PM - Кусочек Interop

Алексей Щепин, автор ejabberd и Tkabber, прилетел вчера из Портленда, где проходил XMPP interoperability testing event. Информации пока немного и фотографий тоже :) Известно только то, что s2s+starttls заработал только у ejabberd и Wildfire, а Google не показали свой сервер вообще, что, впрочем, неудивительно :) В общем, надо будет распросить Алексея по-подробнее, а также дождаться отчёта от stpeter'а :)

psa_and_aleksey

(2 comments | comment on this)

Sunday, July 23, 2006

6:16PM - XMPP vs SIMPLE

Пока Пётр Диденко толчёт воду в ступе, называя jabber-разработчиков пионерами и рекламируя свой CGP, Peter Saint-Andre совместно с инженерами IBM предпринимают более конструктивные действия. Напомню, что около пяти месяцев назад был выпущен IETF Draft, целью которого является interoperability между XMPP и SIMPLE сетями. Окончательное решение по поводу судьбы этого стандарта будет вынесено 18-го августа 2006 года. Если всё пройдёт гладко, мы получим RFC стандарт по совмещению XMPP и SIMPLE. Дальнейшие проблемы лягут на плечи разработчиков :) Но я не думаю, что будет очень большой проблемой "скрестить" ejabberd с Yxa. Вот только как это воспримут авторы этих проектов - не знаю :)

(22 comments | comment on this)

Saturday, July 22, 2006

5:03PM - LDAP и ejabberd

Несмотря на мои многочисленные просьбы, Алексей Щепин ещё не посмотрел мои патчи для усовершенствования поддержки ёжиком LDAP'а. Тем не менее, я продолжаю работать над shared rosters на основе LDAP. Основная проблема заключается в правильном построении шаблонов ростеров. Дело в том, что существующий подход, который щас реализован в ejabberd и Wildfire - простое использование групп и указания связи ростеров с группами. Как показала практика, такой подход несколько ограничен. Так, например, нельзя добавить одного юзера ко всем в ростер, либо добавить "всех" всем в ростер. Поверхностное решение проблемы - использование регулярных выражений в шаблонах ростеров. Видимо так я и сделаю.

(comment on this)

Friday, July 21, 2006

6:29PM - Google упражняется с Service Discovery

Вчера я обнаружил, что GTalk зачем-то прикрутил к своему серверу Service Discovery. Если быть точнее, то только disco#info. Если быть ещё точнее, то оно доступно только по c2s (на s2s-сессии отвечает service-unavailable).

На диско-запрос отвечает следующей станзой:

<iq from="gmail.com" type="result" id="disco1" to="xramtsov@gmail.com/Psi" >
<query xmlns="http://jabber.org/protocol/disco#info">
<identity category="server" type="im" name="Google Talk" />
<feature var="http://jabber.org/protocol/disco#info" />
<feature var="google:jingleinfo" />
<feature var="google:roster" />
<feature var="google:nosave" />
<feature var="google:setting" />
<feature var="google:shared-status" />
<feature var="http://jabber.org/protocol/disco#info" />
<feature var="google:mail:notify" />
</query>
</iq>

Ну и хули это всё значит, спросит читатель, нихера не соображающий в XMPP, но каким-то образом попавший на этот блог. На самом деле здесь много интересных вещей. Во-первых, режет глаз дублирование фичи "http://jabber.org/protocol/disco#info". Вроде как бы JEP'ом это не запрещено, но тем не менее похоже на баг. Во-вторых, и что самое интересное, стандартизованные фичи этим disco#info и заканчиваются: всё остальное имеет префикс "google:", следовательно это нифига не стандартно. Даже хвалёный, весь из себя стандартный jingle, и тот судя по всему реализован через какой-то "google:jingleinfo". На прямые диско-запросы всех фич кроме "google:jingleinfo" гуглесервер отвечает робким service-unavailable, а на "google:jingleinfo" вообще нихера не отвечает (что является нарушением IQ Semantics).
А теперь, собственно, вопрос: на кой хер GTalk  disco, да ещё и c2s-only? Ведь нативный клиент не умеет дискаверить сервисы, а те клиенты, которые умеют, всё равно ничего там не увидят (да и не нужны они гуглю особо). Тут есть два варианта: либо google "подтягивается" к interop (да-да, они туда тоже зачем-то приедут), либо они хотят ввести поддержку Service Discovery в свой кастрированный клиент :) Поживём - увидим.

(2 comments | comment on this)

Advertisement