Realtime на вашем ресурсе за несколько минут

[zoommy]

А в сторону NodeJS & Socket.IO не смотрели? Там все намного проще, как по мне. Мы используем, а в качестве хранения данных и обработки каналов Redis с его pub/sub. Скрипт на ноде получился простейший, а на клиенте так вообще 2 строки — обычная подписка на событие, которое прозрачно проксируется на сервер с помощью Socket.IO

[CCgames]

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

[zoommy]

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

[MechanisM]

Я раньше пользовался данным модулем но потом перелез на использование github.com/wandenberg/nginx-push-stream-module

[alekciy]

Я так понимаю, в сторону RabbitMQ тоже не смотрели?

[student_ivan]

На всякий случай оставлю тут коллекцию comet-решений:

github.com/LearnBoost/socket.io (node.js)
github.com/yrashk/socket.io-erlang (erlang)
github.com/mochi/mochiweb (erlang)
github.com/ibdknox/socket.io-netty (java)
github.com/eclipse/jetty.project (java)
github.com/benkay/java-socket.io.client (java)
github.com/Ovea/Socket.IO-Java (java)
github.com/Gottox/socket.io-java-client (java)
github.com/cometd/cometd (java)
github.com/Atmosphere/atmosphere (java)
github.com/ignacio/LuaNode-Socket.IO (lua)
github.com/vti/pocketio (perl)
github.com/DmitryKoterov/dklab_realplexor (perl)
github.com/madari/go-socket.io (go)
github.com/MrJoes/tornadio2 (python)
github.com/MrJoes/tornadio (python)
github.com/knsd/gevent-socketio (python)
github.com/powdahound/twisted (python)
github.com/gameclosure/orbited2 (python)
github.com/facebook/tornado (python)
github.com/stephenmcd/django-socketio (python)
github.com/dkastner/Socket.io-ruby (ruby)
github.com/markjeee/Socket.IO-rack (ruby)
github.com/maccman/juggernaut (ruby)
github.com/simb/FlashSocket.IO (flash)
github.com/APE-Project/APE_Server ©

[jandosul]

danga.com/djabberd/

[qweewq]

А кто-нибудь пробовал это реализовать на сокетах? Это же в разы быстрее должно быть, и поддерживается мобильными устройствами (без использования браузера).
Никто не хочет помочь с простейшей реализацией приложения?

[DmitryKoterov]

А чем именно dklab realplexor подвел и почему это ожидалось? Там есть C++-версия, которая работает даже под очень высокими нагрузками. И с задержками не должно было быть проблем…

[CCgames]

Мы ставили перл. первый эксперимент был с очень высоким хайлоадом (порядко 600к-1кк уников в сутки), это было примерно пол года назад. основная проблема, которая возникала — если на канал А не приходят сообщения (не отправляются), а на каналы Б-Я сообщения отправляются довольно часто, то при отправке сообщения на канал А его доставка происходила от 5 до 30 секунд. В принципе, такое наблюдалось и раньше, при попытке поднять риалплексор, на ВПС, но тогда я грешил на убогий сервер.
В то же время, сообщения, на самые активные каналы доставляются практически моментально, то есть эти каналы не чувствуют задержек в основном, но вот неактивные очень страдают.
В нынешней ситуации, я полагаю, проблема была схожей, так как некоторые пользователи, да и сами пару раз натыкались на аналогии, ожидали сообщений с кометы по 5-15 секунд, но на этот раз, если сопоставлять ресурсы сервера и нагрузку на него, то это в сотни раз производительнее, чем было под хайлоадом. то есть, что я хочу сказать — на текущем железе, при мизерном онлайне, ситуация возникала та же, что и на более слабом железе, при более сильном хайлоаде.
то есть, либо мы не правильно настраиваем конфиги (хотя весь форум ваше перерыли), либо есть какая то бага с малоактивными каналами.
я был бы вам признателен, если бы вы смогли обьяснить, в чем может быть проблема, так как ваша библиотека довольно удобна и легка в использовании, но на текущий момент, к сожалению, мы не можем ее использовать, так как моментальность доставки сообщений очень важна.

[DmitryKoterov]

Надо смотреть воспроизводимость конкретно в вашем случае. Каналы независимы, не должна загруженность одних каналов влиять на доставку в других. В вашем примере когда вы отправляете данные в канал A и метод отправки возвращает управление в вызывающий код, данные уже в памяти realplexor-а. Теперь любой клиент, подключившийся к А с правильным идентификатором, сразу же получит эти данные (т.к. они просто достанутся из памяти) — тем более вот вы говорите, что при запросе активных каналов ответ приходит сразу же, а значит, перегруженности очереди запросов нет. Т.е. если для одного канала запрос клиента отстреливается моментально, то и для любого другого канала запрос тоже будет моментально отстреливаться, если есть данные. И наоборот, если есть тормоза, то одинаково будут тормозить как активные, так и неактивные каналы.

Я думаю, вы просто где-то неверный изначальный курсор передавали, или еще что-то.