Начинаю экспериментировать с веб-сокетами.
Кто-нибудь знает сервер веб-сокетов (с открытым исходным кодом или платный), который обеспечивает надежное хранилище «канала» веб-сокетов? Все примеры, которые я нашел, не касаются надежности - если сервер веб-сокетов выходит из строя, все данные «канала» теряются.
Такие службы, как Pusher, на самом деле не обсуждают, решают ли они проблему долговечности (и я еще не получил ответа от технической поддержки).
Я счастлив кататься самостоятельно, но предпочел бы не изобретать велосипед.
РЕДАКТИРОВАТЬ:
Я не ищу информацию о веб-сокетах 101. Это легко доступно и понятно.
Я ищу сервер (с открытым исходным кодом или платный), который поддерживает веб-сокеты и имеет надежное хранилище для данных веб-сокетов, чтобы в случае сбоя сервера новый сервер мог занять место там, где остановился исходный.
Две основные цели: 1. Поддержка сценариев аварийного переключения, предусмотренных сетевой рабочей группой веб-сокетов. http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02#section-5.1 (самое главное, чтобы пропущенные сообщения отправлялись, когда клиент подключается к серверу аварийного переключения) 2. Сценарии поддержки, в которых новые подписчики должны получать все прошлые опубликованные сообщения.
Конечно, это можно сделать на уровне приложения ... но я не это ищу.
РЕДАКТИРОВАТЬ
Итак, после некоторого исследования, следующие установленные опции кажутся наиболее надежными:
Хостинговые службы, которые кажутся "настоящими"
Все вышеперечисленные службы имеют постепенный откат к другим методам связи, если веб-сокеты недоступны.
Мне не удалось найти ни одного открытого источника, который обеспечивал бы кластеризацию "из коробки", отказоустойчивость и надежное хранилище сообщений для воспроизведения истории. Есть несколько проектов, которые могут послужить хорошей отправной точкой, но это не совсем то, что я ищу.
Hornetq - это общий брокер сообщений, поддерживающий JMS, STOMP и Websockets + Stomp. Он обеспечивает надежность сообщений наряду с множеством других функций.
Чтобы ответить на ту часть вопроса, которая спрашивает: Толкатель я могу подтвердить, что если пользователь, который был подключен к службе Pusher и серверу WebSocket, к которому они были подключены, умер, он будет автоматически повторно подключен к другому серверу WebSocket. Данные канала существуют только на сервере WebSocket как временные данные, и у нас есть полностью отдельная система, которая позволяет нашим серверам WebSocket распространять и потреблять информацию от подключенных клиентов. На данный момент мы не храним информацию в Pusher. Данные просто распределяются между подключенными компонентами, такими как наш REST API и подключенные клиенты.
На данный момент, если сообщения были отправлены во время повторного подключения клиента, этот пользователь пропустил бы эти сообщения. Однако мы реализуем историю каналов, что означает, что мы будем сохранять данные в каналах. Это будет означать, что любые сообщения, которые пользователь пропустил, могут быть восстановлены. Поскольку наши серверы WebSocket не будут иметь дело с сохранением данных, если мы потеряем сервер WebSocket, мы не потеряем данные канала.
Что вы имеете в виду под данными канала?
Приложение, работающее на сервере, должно заботиться о данных (подумайте о LAMP).
Просто подумайте, сколько данных сохраняется, когда вы создаете HTML-файл с формой, которая отправляет сама себе, и просто помещаете это в простой apache. Все "данные формы" теряются после каждого запроса.
РЕДАКТИРОВАТЬ:
Вы ошиблись.
Веб-сокеты не имеют никакого отношения к устойчивости или долговечности, как и SMTP, HTTP или IMAP. Это просто описание транспорта. (Черт, даже системный журнал не говорит о постоянстве в RFC)
Я не знаю, что вы ищете, но я почти уверен, что это не долговечность байтов, отправленных или полученных через веб-сокет, а стойкость данных, созданных после отправки байтов.
Эта проблема решалась пару раз, я просто буду ссылаться на стандартные рамки СУБД:
Если вы отправляете только JSON, вы также можете использовать какое-нибудь нереляционное хранилище, такое как Riak, Redis, MongoDB, CouchDB.
Конечно, вам нужно проанализировать данные и создать из них что-то, что будет работать для вашей установки. Ненавижу это говорить, но сохранить то, что было отправлено через веб-сокет, не зная его значения, почти то же самое, что взять tcpdump и затем прочитать его с помощью ed.
Могу я предложить перенести этот вопрос в stackoverflow. Я не думаю, что serverfault - подходящее место для архитектуры и разработки фреймворка.
PubNub - http://www.pubnub.com/ - автоматически обеспечивает долговечность канала. Автоматически означает: когда 3G / 4G / WiFi падает, при повторном подключении доставляются пропущенные сообщения; автоматически. Это полезно для мобильных клиентов, которые постоянно находятся в движении с нестабильными сетевыми подключениями. Кроме того, PubNub предоставляет API для проверки истории отправленных сообщений.
PubNub является бесплатным, и вам не нужно регистрироваться, чтобы использовать его. Доступны дополнительные платные функции.
Ознакомьтесь с последним запуском мобильного приложения PubNub Powered: http://www.projectmos.com/
Итак, после некоторого исследования, следующие установленные опции кажутся наиболее надежными:
Хостинговые службы, которые кажутся "настоящими"
Все вышеперечисленные службы имеют постепенный откат к другим методам связи, если веб-сокеты недоступны.
Мне не удалось найти ни одного открытого исходного кода, который обеспечивал бы кластеризацию «из коробки», отказоустойчивость и надежное хранилище сообщений для воспроизведения истории. Есть несколько проектов, которые могут послужить хорошей отправной точкой, но это не совсем то, что я ищу.