Единый API на РНР для всех облачных push-сервисов

    Приветствую всех читателей. Сейчас в веб-разработках столько трендов, что не уследишь. Но вопрос о реал-тайм взаимодействии с пользователями сайта стоит остро прочти для любого проекта. Простейший способ — поставить один из широко доступных открытых comet-серверов, например, Dklab_Realplexor, Socket.IO или Faye — что кому по душе или в зависимости от стека технологий. Правда это путь достаточно сложных проектов, где команда может себе позволить такое решение.

    Для многих проектов попроще (хотя это всегда вопрос конкретики приложения) логично будет использовать сторонние решения. А проще — арендовать как услугу функционал comet-сервера. Сегодня недостатка в таких сервисах нет, так что нам есть что обозревать.

    И так, сначала давайте кратко ознакомимся с существующими push-сервисами, которые позволят нам без создания и поддержки своей серверной инфраструктуры поддерживать реал-тайм общение между клиентами проекта.

    Таких сервисов всего 6: Pusher, Pubnub, Partcl, BeaconPush, X-Stream.ly и ioBridge (с некоторыми особенностями). Под катом — кратки обзор всех сервисов, особенностей РНР-библиотек для них и описание библиотеки pushBridge.IO для унификации работы со всеми облачными пуш-сервисами.

    Pusher.com

    Самый известный из подобных сервисов. Одновременно с этим и один из самых сложных из-за обилия возможностей. В общих чертах, коммуникация поделена на каналы, внутри которых есть пользовательские события, на которые подписывается клиентский код (javascript). Кроме этого есть ряд системных событий, а также система статусов и оповещений и подключениях/отключениях других пользователей канала. Возможна и работа с приватными каналами, так, что даже подключенный пользователь, но не знающий кодового идентификатора, не будет получать события.

    Для взаимодействия с другими системами, Pusher использует REST-HTTP-API (впрочем, как и все подобные сервисы), и предоставляет ряд готовых библиотек для 11 языков, включая Clojure, Groovy и ColdFusion. Меня интересовал только РНР API, который представлен 4-мя плагинами — для Kohana, Code Igniter и бандл для Simfony 2 фреймворков, а также одним независимым классом (http://github.com/squeeks/Pusher-PHP). Для работы он требует расширения cURL и json, а также sha256 в качестве алгоритма хеширования.

    В качестве примечания скажу, что именно с этого сервиса возникла идея моей библиотеки. Буду честен — для одного проекта мне понадобился реалтайм, а в тестовой версии писать свой сервер не хотелось, поэтому за пару минут я думал подключить пушер, тем более, аккаунт у меня уже был. оказалось, что при всех достоинствах и обилии документации, система не такая простая, и не все моменты там удачно расписаны. очень помог режим дебага, когда на сайте в разделе консоли выводятся в реальном времени все ваши запросы, отправляемые через API. Но где-то я ступил и хотя запросы посылались, до клиента они не доходили. На этом месте, после часа отладки я забросил это дело. Перспектива снова переписывать код мне совсем не нравилась, к тому же, в финальной версии моего проекта все равно пришлось бы переходить на собственный сервер. Так и возникла идея — а зачем каждый раз все переписывать, если можно попробовать свести все в один унифицированный интерфейс. Забегая вперед, скажу, что идея успешно нашла свою реализацию!

    PubNub.com

    Этот сервис проще и, в этом, я вижу его преимущество. API предельно прост — есть каналы, в них сообщения и все. Формат данных, конечно, везде JSON. Как в клиентской части, так и на серверной стороне, Pubnub имеет самое широкое покрытие, предоставляя доступ к сервису на любой платформе и языке программирования. Простота и мощная поддержка всех платформ делает этот сервис самым интересным из рассматриваемых, особенно, если вам надо обеспечить реалтайм везде и всюду.

    PHP библиотека для доступа к сервису достаточно простая, позволяет как отправлять, так и получать сообщения, базируясь на cURL. Работает как на 5.2, так и на 5.3 версии РНР, позволяю использовать плюшки вроде callback функций. После исследования исходного кода остался большой вопрос — почему-то при отправке, после преобразования в JSON, длина сообщения не должна превышать 1800 символов! С чем связанно это ограничение пока не ясно, буду связываться с разработчиками и выяснять.

    Partcl.com

    Достаточно новый сервис на этом рынке, первоначально ориентирован на встраивание обновляемых в реальном времени тегов на веб-странице. В настоящее время API там достаточно расширен и позволяет получать историю изменения значений, строить графики, также работающие в реальном времени и т.п. В отличие от остальных сервисов, позиционируемых лишь как коммуникационные, Partcl работает и как контент-провайдер, сохраняя все сообщения и данные, что достаточно уникальная функция. Раскрывая некоторые подробности, скажу, что серверная часть написана на Node.JS+Redis (именно реал-тайм “раздавалка” — я ее непосредственный разработчик), а веб-часть на Zend Framework.

    Хотя для системы уже был написан API на РНР, и даже плагин для интеграции в Wordpress, он, по моим меркам, был достаточно примитивный и вполне мог не работать на некоторых хостингах. Так что я попытался еще и написано новую реализацию библиотеки для partcl-а. Получилось даже лучше, чем оригинальная.

    BeaconPush.com

    Малоизвестный сервис, однако единственный, который предлагает выделенный сервер для требовательных клиентов (система, кстати, написана на Java). А так, он обычный, правда кроме каналов и сообщений выводит наверх еще и абстракцию пользователя, упрощая коммуникацию именно между конкретными подключенными клиентами. Кроме этого, интересный функционал веб-хуков, когда сервис сам дергает указанный вами URL, сигнализируя про вход/выход пользователей из канала. Также есть возможность управлять возможностями публикаций — если не включить ее, любой, зная публичный ид, сможет публиковать данные, иначе только имея секретный ключ.

    А вот с РНР API у этого сервиса никак не сложилось. Он, конечно, есть (https://github.com/ImDom/BeaconPush-PHP и даже модуль для Code Igniter-а), но качество… очень далекое от хорошего. Кстати, автор модуля зашил в исходник свой аккаунт. Честно попытавшись использовать готовый модуль, но так и не смог его настроить на правильную работу (тупо отказывался принимать мой ид аккаунта), я полностью переписал его API под Zend_Http.

    X-Stream.ly

    Еще один почти неизвестный сервис, однако обладающий рядом интересных фишек. Например, можно создавать специально ключи для регламентирования доступа конкретных юзеров к API (видимо из-за бизнес модель). Также, он единственный, кроме Partcl-а, обладает функционалом постоянного хранения сообщений. Другие возможности более-менее стандартные — каналы, события, приватные каналы с доступом по паролю, статусы пользователей. Уникальной фичей является твиттер-фид, когда сервис сам будет подключаться к указанному Twitter-аккаунту и транслировать новые сообщения всем подключенным пользователям. На событие появления сообщения в канала можно поставить калбеки, которыми также можно управлять через REST-API. Кстати, этот сервис единственный, кто для публикации (и вообще, доступа) к своему HTTP API, кроме ид и секретного ключа, требует и HTTP-авторизацию, используя логин и пароль вашего аккаунта, а также работу только через SSL-соединение, что вносит дополнительные требования к хостингу.

    Родной серверный API у сервиса более чем скудный — C#, Ruby и Node.JS. Пришлось с нуля реализовать часть их API, так что здесь я первый, кто написал библиотеку.

    ioBridge.com

    Самый интересный и странный сервис, не совсем даже push. Он ориентирован на подключение к вебу всяких железок (контроллеров и плат), а также обеспечивает отображение данных, сбор и хранение, ну и управление через веб. Родного клиента на РНР также нет, в официальном форуме есть несколько предложений и набросков кода, однако они далеки от качественной реализации. Да и я понял почему, начав сам его делать — сервис местами очень уж странный, например, чтобы получить actionId виджета и ид сессии, надо сделать запрос к их серверу, который сразу возвращает кусок HTML+JavaScript, из которого тупым парсингом строк приходиться выуживать данные, которые потом нужны для подключения и отправки команд. К сожалению, дальше базового кода я не смог продвинуться, видимо, для полноценного тестирования надо и само устройство какое-нибудь подключить. Так что этот код не протестирован в реальных условиях, если кто имеет опыт работы с сервисом, буду благодарен за подсказки и посильную помощь.

    А теперь о самом главном — pushBridge.IO PHP Library



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

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

    Библиотека разделена на две части — базовый класс отвечает за инициализацию нужного адаптера, обрабатывает сообщение, при необходимости, сериализирует его. Для этого я использовал класс Zend_Serializer, таким образом, поддерживаются все его форматы — от обычного Json до экзотического Wddx.

    За работу с конкретным сервисов отвечает класс адаптера, который, при необходимости, подключает родную библиотеку. Пока родные классы используются только для Pusher-а и PubNub-а, ввиду того, что сервисы предоставляют свои специфические функции, которые пока не перенесены. Зато после инициализации вы всегда можете продолжить работать напрямую, просто вызвав метод getConnection().

    Я так же попытался как-то унифицировать данные для авторизации. Одни сервисы используют app_id и секретный ключ, другие именуют их publish и subscribe/public ключами и т.п. Потому я попытался свести их к минимальному множеству и сохранить одно наименование для всех сервисов:
    • appId — обычно это ид приложения или API-key, уникальный идентификатор аккаунта или приложения
    • authKey — секретный ключ, дающий право на публикацию данных
    • secretKey — пароль или другой секретный ключ для доступа к аккаунту
    • readKey — публичный ключ для подключения в качестве клиента и чтения данных
    • emailKey — логин пользователя в виде e-mail (пока это исключительно для x-Stream.ly)


    Для работы с библиотекой достаточно трех строк:

    1. Инициализация и подключение.


    $push = new pushBridge_IO( [ Adapter ], [serializer] );

    Первым параметром идет экземпляр адаптера для нужного вам сервиса, например:

    new pushBridge_Adapter_Pusher(Array('appId' => 'Your app Id', 'authKey' => 'Your key', 'secretKey' => 'Your secret key', 'debug' => true));



    Обычно, достаточно только данных для авторизации, набор которых специфичен для сервиса. Но библиотека, в отличие от родных классов, позволяет гибко управлять методами подключения, используя сетевой стек от Zend_Http. Для запросов можно использовать cURL, напрямую сокеты или адаптер для работы через прокси. По умолчанию используется cURL, но если вам надо, передайте в качестве параметра httpAdapter название нужно адаптера, а в httpAdapterConfig — любые его настройки согласно документации по ZF (например, вот здесь). Каюсь, в этом моменте есть еще баг в текущей реализации библиотеки, пока опции, заданные пользователем для адаптера, не используются, это будет исправлено в следующей версии (на днях).

    Так как разные сервисы требуют (или наоборот) разные методы, можно задать в параметре method каким образом адаптер будет подключаться к серверу. Обычно это GET, но иногда сервисы понимают только POST. Адаптер это учитывает, но вы можете переопределить этот параметр.

    Библиотека вставляет свой кастомный хедер в запрос, X-Powered-By, идентифицируя себя, при желании это можно отключить для экономии сетевого трафика или просто из принципа.

    Второй параметр — сериализатор, который будет обрабатывать сообщение. Все сервисы принимают или JSON, или (некоторые, например, Partcl) просто строку, без преобразования. Изначально там json, используя класс Zend_Serializer, однако вы можете переопределить на любой другой. Достаточно передать в качестве второго параметра или строку с названием сериализатора (сейчас поддерживаем: json, php и pickle) или сразу экземпляр класса Zend_Serializer с необходимыми вам опциями.

    Примеры:

    Partcl:
    $push = new pushBridge_IO( new pushBridge_Adapter_Partcl(Array('secretKey' => 'Your secret key')) );
    Pusher:
    $push = new pushBridge_IO( new pushBridge_Adapter_Pusher(Array('appId' => 'Your app Id', 'authKey' => 'Your key', 'secretKey' => 'Your secret key', 'debug' => true)) );
    Pubnub:
    $push = new pushBridge_IO( new pushBridge_Adapter_Pubnub(Array('readKey' => 'Your subscribe key', 'authKey' => 'Your publish key', 'secretKey' => ' Your secret key')) );
    BeaconPush:
    $push = new pushBridge_IO( new pushBridge_Adapter_Beaconpush(Array('authKey' => 'Your API Key', 'secretKey' => 'Your secret key')) );
    А во пример с кастомным сериализатором:
    $push = new pushBridge_IO( new pushBridge_Adapter_Partcl(Array('secretKey' => ' Your secret key')), ‘php’ );
    или
    $push = new pushBridge_IO( new pushBridge_Adapter_Partcl(Array('secretKey' => 'Your secret key')), Zend_Serializer::factory('Wddx', Array(‘comment’ => ‘Powered by ZF+pushBridge.IO’) );

    2. Просто отправляем сообщение.


    На самом деле все не так и просто. Сервисы очень по разному работают с сообщениями. Самое простое — это модель канал->сообщение (или тег -> сообщение), другие же вносят новый уровень — канал -> событие -> сообщение. При этом только partcl очень толерантно относиться к содержимому сообщения, для него это просто строка, а ее понимание перекладываться полностью на клиента. Другие требуют специального оборачивания сообщений в json-структуры. Ни один из сервисов не поддерживает массовую отправку сообщений, когда в одном запросе можно было бы публиковать данные в разные каналы или несколько разных сообщений и событий в один канал. Этот момент мы уже учли и в следующей версии нашего сервиса Partcl.com такая возможность будет, параллельно в библиотеке появиться и эмуляция этого функционала для всех остальных (справедливости ради стоит сказать, что такой функционал реализован в классе для BeaconPush, но не портирован в мою библиотеку).

    Общий метод отправки имеет такой вид:

    $push->send( 'сообщение', 'channel', 'config' );

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

    Если в сервисе используются каналы, то второй параметр это строка (или массив) каналов, куда следует отправить сообщение. если каналов нет, это ид тега или другой ид.

    При необходимости задать код события следует использовать конфиг — третий параметр всегда массив. Событие задается в параметре event. Дополнительно можно отключить сериализацию, передав параметр serialize = false. Если сервис принимает, можно указать и дополнительные параметры сообщения, например флаг сохранения данных для X-Stream.ly или включить/отключить дебаг-режим для сообщения в Pusher-е.

    Пример отправки простого сообщения:

    Partcl:
    $push->send('Hello world from pushBridge.IO', 'Your tag id', Array('serialize' => false));
    Pusher:
    $push->send('Hello world from pushBridge.IO', 'test_channel', Array('serialize' => false, 'event' => 'push_test', ‘debug’ => true));
    Pubnub:
    $push->send('Hello world from pushBridge.IO', 'my_channel');
    x-Stream.ly:
    $push->send('Hello world from pushBridge.IO', 'mychannel', Array('event' => 'my_event', ‘persisted’ => true));

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


    Исходный код библиотеки и краткие примеры:github.com/aleksraiden/pushBridge.IO/tree/ServiceWrapper

    В планах на ближайший релиз: исправление ошибок, унификация метода send, поддержка публикации сразу нескольких переменный, реализация метода чтения данных, а также поднятие сайта проекта на домене pushcloudapi.com. Буду благодарен за замечания и дополнения.
    Поделиться публикацией

    Похожие публикации

    Комментарии 35
      0
      Честно говоря не первый раз натыкаюсь на эти сервисы но так и не понял зачем их юзать. Вот простой небольшой проект. На нем чат. Зачем мне юзать эти пушеры если я просто делаю выборку из базы и кешу ее на пару секунд скажем. Или что-то подобное.
      Подскажите тугодуму где они скажем ОЧЕНЬ нужны? Потому что я видимо что-то упускаю.
        0
        Без сарказма, правда хотелось бы понять. Может действительно пригодится.
          +3
          Для реализации реал-тайм и стрима. Иначе придеться ставить свой сервер, поддерживать разные протоколы веб-сокетов, флабек для других версий и т.п. инфраструктуру.
            –4
            Ну что значит реал-тайм, стримы? Какой-то постоянно обновляемый элемент (блок с текстом скажем) на сайте? Ну я через jquery буду делать ajax-запрос раз в секунду например к пхп-скрипту и все. Или речь идет о чем-то другом?
              +4
              ~100 запросов в секунду от 100 пользователей, мистер да вы самоубийца.
                0
                Ну тут можно навскику даже несколько вариантов придумать. Обращаться к мемкешу, или демоном ложить сформированный хтмл файликом а клиенты будут его подтягивать, без пхп и базы вообще. Наверняка куча хороших решений на просторах сети есть.
                В чем преимущество именно использования описанных сервисах? Именно когда очень большие нагрузки и чтобы не париться а быть уверенным что все будет тип-топ работать видимо?
                  +3
                  Преимущество их в том, что они легче, чем то, что вы описываете… Вот и все.
                    0
                    Довод понятный — возможно кому-то легче мемкаше поднять и написать скрипт, а кому то зарегистроваться на сторонем сервисе, почитать доки, и написать скрипт.

                    Маштабируемостьразве что на стороннем сервисе должна легче решаться, без головной боли. Два мемкеша настроить на двух серверах под один апликайшен сервер — ето не в два раза больше заплатить на сторонем сервисе.
                      0
                      Одним мемкешем не обойтись — с какого-то момента надо и кластер строить и решить вопрос множества паралельных конектов и т.п. Конечно, если проект и команда такого уровня, то это делаеться собственным. Для множества других случаев построение такой инфраструктуры и ее поддержка излишняя.
                    +2
                    Почитайте для начала статейки про сокеты, про Node.js и прочие подобные штуки. Тогда вопросы отпадут сами-собой.
                      0
                      Все простые решения работают до определенного момента. Дальше они не работают, а работает то, что описал автор. За что ему и спасибо.
                        0
                        Для разработки данного функционала уйдет более 2-3 недель если окончательно. Если Ваш рабочйи день оплачивается ~$100 то это крайне не выгодно.
                        +1
                        а в чем проблема? Живой пример — 8 ядерный дедик отдает 30мегабит в пике с лоад аверайдже менше 0.4, в скрипте около 30 запросов к одной таблице, и 3 закешированых в мемкаше запроса к двум таблицам. Проблемы были сначала, после анализа все решения, где накапливалось больше ляма рекордов в таблице пришлось выбросить или переделать под мемкаше.

                        Сервер покруче думаю без проблем отдаст гигабит.

                        В посте решение без примера — поєтому и решение непонятно. Цитата с поста явное преувеличение- «Но вопрос о реал-тайм взаимодействии с пользователями сайта стоит остро прочти для любого проекта» — попробую придумать пример — таньчики онлайн:

                        Есть 1000 полигонов, на каждом по 10 игроков. Существует риск пиковых нагрузок в 10000 полигонов. Также каждый игрок может редактировать свой профайл. Милион пользователей в базе, активных 100 тисяч, играют в среднем 10к.

                        Я так понимаю автор описывает проблему взаимодействия игроков на полигоне.
                          0
                          а в чем проблема? Живой пример — 8 ядерный дедик отдает 30мегабит в пике с лоад аверайдже менше 0.4, в скрипте около 30 запросов к одной таблице, и 3 закешированых в мемкаше запроса к двум таблицам. Проблемы были сначала, после анализа все решения, где накапливалось больше ляма рекордов в таблице пришлось выбросить или переделать под мемкаше.

                          Сервер покруче думаю без проблем отдаст гигабит.

                          В посте решение без примера — поєтому и решение непонятно. Цитата с поста явное преувеличение- «Но вопрос о реал-тайм взаимодействии с пользователями сайта стоит остро прочти для любого проекта» — попробую придумать пример — таньчики онлайн:

                          Есть 1000 полигонов, на каждом по 10 игроков. Существует риск пиковых нагрузок в 10000 полигонов. Также каждый игрок может редактировать свой профайл. Милион пользователей в базе, активных 100 тисяч, играют в среднем 10к.

                          Я так понимаю автор описывает проблему взаимодействия игроков на полигоне.
                            0
                            глюкавит чьот хабр
                          +2
                          Зачем делать раз в секунду запрос от клиента к серверу, если сервер может сам раз в час сообщить клиенту, что произошло событие, о котором клиенту нужно знать?

                          Бог с ней нагрузкой на сервер, а пользовательский трафик? Пускай 256 байт запрос и 256 ответ, 512 байт в секунду, 30 КБайт в минуту, 1,8 Мбайт в час, а это, например, почти 15 руб на моем тарифе в телефоне.
                        0
                        Сообщение там пришло, тут лайкнули фотографию, здесь запрос в друзья пришел… «Дешевле» все это добро доставлять, через Push сервисы, чем каждую секунду стучаться аяксом.
                          –1
                          Facebook же стучит аяксом?
                            0
                            Дешевле стучаться к кому-то, чем к себе. И там не просто периодический аякс, а просто длинные запросы, которые крутятся на сервере пока не появится ничего нового.
                              +4
                              вообще, конечно, дешевле раз соединиться и ждать. Хотя здесь много нюансов — разные техники комета стоит применять в зависимости от особенностей событий и как часто они изменяются.
                                0
                                События, по хорошему, должны в один стек падать, который и будет проверяться в цикле запроса к серверу.
                                  +2
                                  Когда стоимость запроса и даже самого соединения больше, чем интервал между обновлениями сами данных, это плохо работает.
                              +3
                              Посмотрите контакт, он немного впереди фейсбука по используемым технологиям.
                              0
                              ага, хороший пример, хорошо бы автор себе в статю утянул.
                              +5
                              пуш сервисы это несколько более широкое понятие нежели просто чат. Но конечная суть та же, обмен сообщениями, только не обязательно между людьми. Формат их можер разниться, отправляться и приниматься они могут по разным каналам и протоколам, читаться/писаться разными людьми или процессами, нагрузка доходить до сотен тысяч в секунду. Храниться это все будет где то где много места и каналы широки. Если Вас устраивает чат на десяток пользователей Вам это пока не надо. Это для тех у кого напр. суппорт атакуют десятки тысяч клиентов, где ответы им удобно группировать в каналы и сообщения по темам (одно на сотню идентичных вопросов), где надо осуществлять предварительную маршрутизацию сообщений (напр. подходящая тема подходящему специалисту суппорта). Причем все это в автомате итп. На самом деле целая наука требующая нешуточных знаний и опыта. Насколько я понял автор попытался дать общий API для разных сервисов дабы можно было ими всеми пользоваться из одного проекта выбирая более подходящий сервис для каждой конкоретной задачи. Вот так если в 2х словах. За это ему и плюсик. Все интереснее нежели очередной обзор как открыть 2 крышки ноута дабы увеличить его память. Чесслово, последнее время, хотелось бы поменьше массы, побольше качества на хабре. И эта статья, на мой взгляд, вполне интересна и заслуживает внимания. С Уважением с Хаброобчеству. Михаил.
                            +7
                            image
                              0
                              В первый раз слышу о подобных сервисах, как-то мимо меня они прошли (видимо потому что гуглил по php push library :( ), хотя идея очень интересная. И как раз столкнулся с необходимостью разбираться с чем-то вроде Dklab_Realplexor. А тут статья на тему как обойтись без него :)

                              Можно несколько вопросов о подробностях общих, чтоб не лазить по документации каждого?

                              1. Безопасность (аутентификация, авторизация). Допустим чат с приватными каналами. На своем сервере я бы проверял права доступа к каналу по session_id, откуда бы вытаскивал user_id, role_id, acl, список каналов и т. п. Как на этих сервисах решается? Надеюсь не только по сокрытию имени канала. Read only клиенты предусмотрены?

                              2. Насколько я понимаю, это получаются cross domain запросы. Что за костыли используются? :)

                              3. Поддерживается ли транспорт WebSocket хоть одним сервисом?

                              4. Цена вопроса. Цены посмотрел. Вопросы не снимаются (частично) :)

                              И вопрос по библиотеке конкретно — насколько трудно будет обернуть свой сервер/демон? Просто по опыту работы с внешними сервисами аутентификации и хранения данных понял, что проще всего и свой «нативный» предоставлять так же как внешний, единственно стараться не по http(s) запросы к нему слать, а через «бинарный» сокет или вообще через вызов функций/методов в реализации общего интерфейса.
                                +2
                                1 — Везде по разному, обычно решаеться внешней аутенфикацией и по итогам — клиенты работают с несколькими каналами, часть из которых паблик, часть — приватные (по факту уникальности имени канала — и это оправдано, ведь клиент то js, толку там от пароля не очень много). Например, у пушера вот статья об этом: pusher.com/docs/authenticating_users В общем случае — это перекладываеться не на клиентов, а на паблишера — кто отправляет данные, тот проверяет доступы и думает, кому отправить. У нас в partcl наоборот, все клиенты read-only, паблиш данных идет только через приложение. У других обычно смешанная модель (публиковать можно и через HTTP-API и сразу из клиента). У пушера публикация данных из клиента также идет по веб-сокету, авторизация по отдельному аякс-запросу (если отправять данные специфическому клиенту, нужно в конфиге метода сенд указать параметр socket_id). У PubNub-а публикация идет через HTTP-интерфейс, как из клиента, так и с любой внешней библиотеки. Это оправданно, так как все эти сервисы ориентированы на ситуации, когда много читателей, относительно немного публикаций или же частота публикаций у одного автора относительно низкая.

                                2 — используют техники, для которых это не помеха. Обычно у всех WebSocket, с фалбеком на флеш-вариант. Снова таки, у нас сначала идет самый простой способ — jsonp-polling, а потом, после начала, уже решаем каким транспортом соединиться (флеш-сокеты или нативные веб-сокеты).

                                3 — Наоборот, вебсокеты это основной транспорт для всех сервисов (исключаем только ioBridge, он специфический).

                                4 — Касательно своего домена/сервиса — Абсолютно не сложно — надо реализовать AbstractAdapter интерфейс и два метода (конструктор и сенд). окей, вы раскрыли мои планы :) Эта библиотека — часть большого проекта, в процессе написания вторая часть, которая будет предоставлять унифицированный (такой-же) интерфейс к большинству опенсорсных и коммерческих хостед серверов (начиная от DkLab Realplexor, заканчивая коммерческими которые могут принимать данные по AMQP или JMQ). Некоторая сложность в том, что далеко не все сервера уимеют специальный выделенные АПИ (Котерову респект, в его проекте это предусмотрено), поэтому для тех серверов, где нет, будем эмулировать клиента (да, вебсокет клиент на РНР и т.п.).

                                В итоге, должна получиться одна библиотека (или сервис), который пушит данные любому клиенту, через любой сервис/сеть/транспорт, связываеться с удаленным сервером по любому варианту RPC, поддерживая даже мобильные пуш-сервисы и социальные сети.

                                если что, пишите вопросы здесь или приватом, думаю смогу что подсказать.
                                  0
                                  Спасибо за подробный ответ, жаль «повторное голосование запрещено» :)

                                  Предложением воспользуюсь попозже, когда до реализации дело дойдёт. Единственное что сейчас ясно, что каждому клиенту нужен один отдельный канал точно и прослушивание его посторонними (вернее конкурентами) крайне нежелательно, сложность брутфорса должна быть сопоставима со сложностью подделки дефолтной сессионной куки в PHP, а события будут генерироваться сервером в результате обработки очереди заданий. И даже если это будет уведомление типа «клиент такой-то стукнись на сервер, для тебя есть новые данные» то что-то из перехвата таких сообщений (частота, время и т. п.) можно, наверное, получить. Плюс продвинутый чат хочется предложить, как элемент социализации и доступа к поддержке.
                                    +1
                                    в одной из моих систем, на реалплексоре так и сделано — кроме паблик каналог у каждого юзера есть свой канал, идентифицируемый как раз по сессии
                                0
                                На счет ограничения у pubnub в 1800 символов интересно.
                                Для меня этот сервис выглядит как идеальное решение, но сие ограничение удивляет.

                                Ваш клас сейчас это как то решает?
                                  +1
                                  В текущей реализации — нет. В следующей версии (думаю, неделя-две) решит. Со мной уже связывались ребята из пабнаба, буду с ними работать по этому вопросу. Если это только в библиотеке, тогда решим, если же это ограничение самого сервиса, то я со своей стороны сделаю обход (в виде разделения на несколько сообщений и контроль целостности), но это потребует некоторого кода на клиенте, который также будет выложен.

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

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое