Blogerator.org

× Версия для печати

Популярность всем привычного протокола RSS, похоже, достигла своего апогея, но жизнь не стоит на месте, и по мере развития концепций Web 2.0, ограниченность и примитивность протоколов RSS разных версий начинает все больше тормозить возможности оперативной подписки и агрегирования  новостей в современном динамическом интернете. К счастью, уже разработаны и успешно завоевывают свое место под солнцем протоколы по подписке новостей и уведомлений нового поколения, среди которых два главных лидера-конкурента, это PubSubHubbub и rssCloud.

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

Протокол PubSubHubBub (часто сокращенно пишут PuSH) определяется в Википедии “как открытый коммуникационный протокол для распределенных публикаций и подписок в интернете. Протокол расширяет уже известные протоколы Atom и RSS”. У rssCloud практически в точности аналогичное определение.

Главная цель всех усовершенствований в обоих протоколах, - это создание механизма практически мгновенного уведомления обо всех изменениях на обслуживающем сервисом. Реализуются подобные уведомления, как правило, на базе т.н. “жирного пинга” (“fat ping”), т.е. уведомления содержащего в себе дополнительную информацию о деталях самого обновления.

Врожденные проблемы RSS

Оба протокола, PuSH и rssCloud, пытаются устранить главные сегодняшние проблемы RSS: чтобы узнать появилось ли обновление, в RSS необходим постоянный поллинг (опрос) целевого ресурса. Когда число таких подписчиков исчисляется десятками тысяч - мы имеем фактически настоящую DDoS-атаку ресурса. Кроме ненужной нагрузки, эта техника просто избыточна сама по себе.

Говоря на простом примере, RSS напоминает собой докучливого ребенка, который постоянно теребит свою маму: “Скоро ты мне расскажешь сказку?”, “Уже совсем скоро?”, “Ты уже готова?” и т.д. с частотой автоматной очереди. Подход обоих новых протоколов, PuSH и rssCloud, заключается в том, чтобы ответить единожды: “Помолчи немного, я сама тебе скажу, когда я буду готова”.

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

Общее в протоколах

Несмотря на то, что упомянутые новые протоколы созданы для одной и той же цели, их конечная реализация несколько отличается. Для начала нашего предметного их рассмотрения, давайте сравним и выделим те общие черты, которые абсолютно аналогичны для обоих протоколов:

• Оба протокола, PubSubHubbub и rssCloud, разрешают хабу новостей физически располагаться на другом сервере, нежели оригинальный сервер, являющийся источником ведущего RSS-канала. Это удобная возможность, она позволяет прозрачно перенести эту ресурсоемкую функцию, если у вас много подписчиков, на отдельный выделенный сервер, или даже воспользоваться специализированным сервисом от сторонних компаний, предоставляющих этот сервис (например, Google);
• Оба сервиса посылают уведомляющий о публикации пинг. Клиент rssCloud может делать очень простой POST-запрос, кроме того, rssCloud для этого может использовать протоколы XML-RPC или SOAP. PubSubHubbub также имеет очень похожую POST-операцию с аналогичной семантикой запроса;
• Оба протокола предлагают очень простой и ясный API, для организации подписки на новостные фиды сторонними инструментами;
• Оба протокола базируются на http.

Отличия в протоколах

В самом деле, эти оба протоколы настолько похожи, то когда речь заходит о выборе, очень часто задается справедливый ключевой вопрос: а чем же объективно они отличаются друг от друга? Попробуем выделить главное в их немногочисленных отличиях:

• PubSubHubbub полностью совместим и поддерживает как RSS, так и Atom сразу после инсталляции. rssCloud не поддерживает в полной мере протокол Atom (ограниченная поддержка), полностью реализуя лишь RSS;
• PubSubHubbub обеспечивает полноценные “жирные пинги” клиентам, тогда как rssCloud предоставляет только самые базовые возможности в своем сервисе уведомлений. Подписчик PubSubHubbub может полностью положиться на сервис уведомлений, отказавшись от традиционного механизма постоянного поллинга фидов. rssCloud требует от подписчика обязательного ре-поллинга новостного фида, после получения каждого уведомительного пинга от сервиса новостей; Именно поэтому, полноценный “жирный ping” имеет как минимум преимущество в том, что он экономит трафик и снижает нагрузку на обе стороны, тогда как в rssCloud по-прежнему, как и в старом-добром RSS, требуется неизбежно совершать много избыточного информационного обмена;
• С другой стороны, создание полноценного “жирного пинга” требует гораздо большей работы со стороны новостного хаба, что при большом количестве подписчиков создает сложные оповещательные очереди, что создает существенно большую нагрузку, по сравнению с сравнительно простой работой хаба rssCloud;
• PubSubHubbub позволяет осуществить подписку любого конечного подписчика путем более гибкого языка запроса (с некоторыми мерами предосторожности, предотвращающими спаминг пингами произвольных хостов), т.е. указать произвольный callback-URL для обработки ответных пингов. rssCloud в этом плане более строг и ограничен: он позволяет подписывать подписчика только с того IP-адреса, с которого был осуществлен пинг-запрос обновления, что потребует обязательного размещения всего софта участвующего в подписке на том же сервере (адресе), на котором находится подписчик. Этот пункт приводит к довольно серьёзным очевидным следствиям, что делает в сравнении протокол PubSubHubbub гораздо более гибким и универсальным;
• Несмотря на более простой и консервативный дизайн rssCloud, у этого протокола уже имеются некоторые проблемы с безопасностью, которые не так-то просто исправить (пример потенциальной DDoS-уязвимости).
• В PubSubHubbub более удобно устроена процедура отписки от мониторинга ленты новостей. В rssCloud каждый фид автоматически считается отписанным после 25 часов с его появления, тогда как в PuSH есть отдельная функция, которая позволяет самому определить промежуток времени “устаревания новости”, а также возможность настройки некоторых других деталей, с этим связанных. Эта мелочь лишний раз подчеркивает, что PubSubHubbub очень бережно относится к избыточности запросов, тогда как в rssCloud единственный способ решения проблемы продления подписки – это переподписка, которая при массовом её применении генерирует большой трафик и существенную нагрузку на новостной хаб, тогда как можно было обойтись лишь коротким запросом продления, как это сделано в протоколе PuSH.

Тем, кто интересуется технической стороной различий более глубоко, рекомендуем начать с этого обзора. Также рекомендуем сравнение возможностей основ этих систем -  жирного пинга (fat pinging), на котором основаны PubSubHubbub и XMPP pubsub, а также легковесного пинга (light pinging), на котором базируются альтернативные системы уведомлений: rssCloud, XML-RPC pings, changes.xml, SUP, SLAP.

Популярность

PubSubHubbub – разработка компании Google, который она затачивала в первую очередь для своего Google Reader, но кроме этого сервиса новый протокол подхватили также: Feedburner, Blogger, Google Latitude, YouTube, PicasaWeb, FriendFeed, LiveJournal, Superfeedr, Google Alerts и многие другие.

Среди крупных игроков в мире rssCloud можно назвать разве что только нативную поддержку в WordPress, что автоматически породило целую армию блогеров-источников новостей в этом формате (кстати говоря, для поддержки в WordPress альтернативного PubSubHubbub также написан плагин). Другая острая проблема, свойственная для rssCloud – ограниченное количество rss-клиентов, способных понимать этот протокол и использовать его в полной мере, на данный момент это лишь River2 и LazyFeed.

Заключение

Сегодня потребность в протоколах уведомлений реального времени велика как никогда. Некоторые крупные порталы не дождавшись подобных решений, пошли своим путем, например, NetVibes, который разработал свой собственный закрытый протокол уведомлений в режиме реального времени. В наши же дни, рекомендуется параллельно транслировать новости (новостные фиды) сразу в оба открытых протокола, чтобы покрыть максимально широкое количество разнородных клиентов.

При необходимости жесткого выбора, более предпочтительным выглядит PubSubHubbub, тем более, что этот протокол стремительно развивается. Так, например, здесь уже полностью реализован шлюз в протокол XMMP (XMPP pubsub) для автоматической трансляции новостей из этого протокола в Jabber или GTalk.