Comet сервер на эрланге

[keylase]

Подскажите, пожалуйста, существуют ли реализации комбинированного сервиса comet (long polling) + websockets?

[erlyvideo]

Да, ковбой это может делать, об этом будет во второй части.

[MechanisM]

Если вас интересует еще и что-то вне Erlang, тогда есть модуль для nginx с таким функционалом.

[erlyvideo]

Тут дело какое: если вам потребуется приделать к этому авторизацию через mysql/постгрес, то усилия, требуемые что бы грамотно заимплементить модуль для nginx будут несравнимы с аналогичным кодом на эрланге.

[MechanisM]

Совершенно согласен, я просто как вариант навскидку вспомнил, и написал. А сфера применения бывает разная — где-то и не требуется авторизация.

[VBart]

Потребуется максимум час, если вы ранее были не знакомы с lua. Модуль postgresql к nginx уже есть, далее дело за малым.

p.s. ничего против erlang не имею, он хороший.

[erlyvideo]

Оставляя в стороне вопросы удобства самого языка, erlang отличается от lua/javascript/ruby/etc концепцией разделяемой между процессами памяти. Это меняет практически всё.

[VBart]

«Практически всё» — это что именно? В nginx тоже есть резделяемая память, и модуль lua содержит достаточно удобный интерфейс к ней.

[Drinker]

Да, существует
github.com/extend/bullet

[Joes]

Да, SockJS.

Есть сервер для эрланга, работает тоже поверх ковбоя: github.com/sockjs/sockjs-erlang

[MechanisM]

Реалтайм работающий на Erlang это всегда хорошо(часто лучше и стабильнее чем NodeJS) и нареканий не возникает.
Я вот только еще учу Erlang. Большое спасибо за пост!

[kliss]

Пфф, да всё что угодно лучше и стабильнее node.js. Даже PHP :)

[MechanisM]

PHP в плане создания реалтайма лучше чем NodeJS?

[VolCh]

А что вы имеете в виду под реалтаймом? Помнится из лекций, что это гарантированное время ответа на запрос.

[MechanisM]

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

[VolCh]

Для меня это просто двухсторонний протокол обмена информацией, server push, comet.

Не знаю, лучше PHP или JS (сравнивать язык с фреймворком вообще некорректно, кстати), но на PHP это реализовать можно, в том числе асинхронно, без форка процесса каждому клиенту. Но над выбором на чем реализовывать сервер-сайд для вебсокетс сам думаю. PHP знаю хорошо лучше других языков, JS — похуже, Erlang — только осовы синтаксиса. А ещё в сторону Ruby с EventMachine смотрю.

[MechanisM]

Ну да, я слышал что «на PHP можно» но чтобы это было лучше и стабильнее чем на NodeJS? — я в этом сомневаюсь.
Вот те-же Вконтакте — сайт на php а xmpp сервер для сообщений написали на NodeJS,
Facebook на php(ну да и hiphop) а сообщения работают насколько я знаю через Ejabberd(Erlang) — даже проекты написанные на php не пишут реалтйм на php.
Да-да Ruby и его EventMachine это тоже то что я подразумевал под реалтаймом.

[VolCh]

xmpp — да, но вот уведомления от приложений или о новом сообщении при просмотре обычных страниц тоже на nodejs у VK?

[seriyPS]

где-то читал что уведомлялка long-polling у них на C

[int03e]

Макс, спасибо, надеюсь что история получит продолжение.

[quantum]

При написании статьи есть кнопочка «Предпросмотр», она нужна для того, чтобы в опубликованной статье не было таких артефактов:

< code>
./rebar compile

[quantum]

</code>

[erlyvideo]

В хабре какой-то глупый парсер HTML-я, который оказался не в состоянии обработать pre и code подряд.

Увы, но это проблема хабра, отдельно под него править статью я не готов.

[kliss]

Так ты статью для другого места писал вообще? :)

[erlyvideo]

Конечно.

[jov]

Хотя может и здесь кросспост и ресурс для которого писалась эта статья нам так и не найти.

[w495]

Макс, оформи код, пожалуйста, через

<source lang="erlang">
    foo(X)-> {bar, X}.
</source>

А то читать, ну совсем тяжело, ни тут, ни в жж.

[w495]

Спасибо!

[akalend]

Макс — спасибо :)
потихоньку точу Эрланг…
пишу лонг-пулл на Сях, работает стабильно

[erlyvideo]

Можно написать на эрланге — время на обучение и написание растворится на фоне времени на написание хорошего, нетекущего сервера на С =)

[w495]

Смотря как писать. Имхо, для некоторых задач подходит написание интерпретатора своего специфического языка (flex, bizon помогут), и написание сервера на этом специфическом языке. Правда нам было лень писать его на С, и мы написали на erlang.

[erlyvideo]

Вот ты лучше расскажи про ваш опыт. Что у вас написано: видеораздача или сайт? Чего интересного было?

[w495]

Ну это похоже на то, о чем говорил Боб Ипполито на конфе в Яндексе. Правила отбора рекламы. В неформальной постановке правила оказались настолько сложными (а мы таки заботимся, чтобы пользователь не посмотрел слишком много рекламы), что для их формализации пришлось написать маленький интерпретатор lisp-подобного языка. По сути это просто набор фильтров. Но фильтры имеют строк действия, условия срабатывания, их можно складывать, вычитать, проводить операции как над множествами.

Из интересного:

1. Интерпретатор не стал бутылочным горлышком, хотя мы этого ожидали. Скорость работы все равно упиралась только в базу (до его подключения упиралось в нее же).
   
   Офтоп:
   

   Во общем не удивительно, c одной стороны. Когда я тестировал erlang (R15 c HiPE) в другом проекте (http://www.slideshare.net/w-495/dsmts-diplomatext, отчати github.com/w495/ngrm-smt), то скорость была сопоставима с C. (Но, без HiPE, к сожалению, нет) Глобально сравнивал с Moses на тех же исходных данных с минимальными настройками для Moses. Локально, на сопственных сишных поделках. От питона, который, в силу обстоятельств, мы вынуждены поддерживать такого ожидать трудно (github.com/w495/ngrm-emt). ngrm-smt и ngrm-emt делают разные вещи, но ngrm-smt включает в себя часть функционала ngrm-emt.
   

   
   
2. Я лично для себя познал всю мощь функций высшего порядка (lists:map, lists:filter и пр) и нативных функций работы со списком тегированных туплов (lists:key*), ибо размер кода они сильно уменьшили. В первой версии интерпретатора все писалось в стиле:
   
   

       handle_list([], Info, Opts) ->
           Info.
       handle_list([Param|Parms], Info, Opts)-> 
          Res = handle_item(Param),
          handle_list(Parms, [Res|Info], Opts).
   

   
   
   Как мне казалось, это эффективнее, чем передавать fun'ы. Но выглядело как нагромождение, чего-то несуразного, тяжело поддерживаемого. На скорость по моим замерам это не повлияло (всего скорее, повлияло на самом деле, но незначительно).
   
3. Очередной раз убедились, что написание интерпретаторов на функциональных языках — не особо сложная задача. Даже при постоянно меняющихся требования. Первый раз я в этом убедился, когда за ночь написал компилятор обрезанной версии питона на lisp, еще в универе. Тогда это представлялось какой-то игрушкой. Но как оказалось подобные вещи весьма полезны. Вообще как, было написано, по-моему и М. Сипсера, чтобы решить проблему, достаточно правильно сформулировать язык ее описания. Ну вот мы и получили подтверждение.
   

Да, к сожалению, вслед за Бобом Ипполито, код предоставить вам не смогу. Придется поверить мне на слово.

[w495]

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