Как стать автором
Обновить

Комментарии 12

Хорошее исследование. Автор — молодец!
Вот за что люблю Perl, так за множество готовых решений. Небольшое исследование CPAN и всё, что угодно можно сделать за кратчайшее время.
Спасибо. С удовольствием еще почитаю про событийное программирование в примерах)
Сервис временно недоступен. Попробуйте повторить запрос позднее.

Хабраэффект
Скорее всего, был обрыв соединений icq. Они восстанавливаются не сразу, а в течение 5-15 минут — можно посмотреть в исходниках :)
К тому же, надо сильно постараться чтобы уронить сервис — асинхронная отработка запросов и лимит 1 запрос на проверку в 15 секунд с 1 айпи не дадут загрузить все 10 icq-соединений. После запроса icq-соединение помечается как недоступное на 3 секунды, для предотвращения его использования для следующей проверки (если этого не делать, то при слишком быстрой посылке сообщений сервер icq может отключить за флуд)
:)

Вы сказали, что пробовали использовать 3 ICQ модуля из CPAN (я так понимаю это Net::OSCAR, Net::AIM и что-то связанное с AOL, там туча библиотек), у меня как-то стояла такая же задача, тоже ни один из модулей не подошел, что бы вы посоветовали для написания простейшего ICQ бота (прием-отправка сообщений)?
Насколько знаю, Net::Oscar рабочий. В принципе, можно использовать мой модуль — там реализована отправка сообщений, и колбэк на принятое сообщение (но нет разбора этого сообщения и выдирания текста сообщения из пакета). При желании можно допилить до полноценного icq-клиента и выложить на CPAN, я этим вряд ли буду заниматься
Скажите, как решается у Вас проблема с «автоподъёмом» демона? Решают ли эту задачу используемые библиотеки?
В моем случае — никак, поскольку отсутствует разделение boss — worker, используется только один процесс. Эта задача отлично решается модулем FCGI::ProcManager.
Спасибо, попробую покапать в эту сторону.
О, приятно видеть, что я не зря выкладывал на CPAN модуль FCGI::EV, он уже кому-то пригодился. :)

Я тоже экспериментирую сейчас с неблокирующими веб-приложениями. Одна из причин — избежать сложного управления процессами (то, что кое-как пытается делать FCGI::ProcManager — но если почитать APUE Стивенсона, то становится ясно, насколько этот модуль наивно написан… так что я бы его никому не рекомендовал использовать в продакшне). Чтобы избежать блокирования при обработке CGI-запросов часть задач веб-приложения выносится в отдельные сетевые сервисы. Получаем сервис-ориентированную архитектуру, отличное масштабирование, и упрощение разработки сложных систем.

По поводу AnyEvent — идея, безусловно, хорошая. Но дело в том, что мы достаточно серьёзно потестировали разные реализации event loop на CPAN, и обнаружили, что реально пользоваться можно только модулем EV — остальные либо глючат, либо грешат утечками памяти, либо тормозят, либо дико переусложнены. А event loop — это сердце приложения, там таких проблем быть не должно! Поэтому я свои модули пишу не на AnyEvent, а на EV.

Кстати, в качестве альтернативы AnyEvent::Handle можете глянуть мой IO::Stream. По сути он делает то же самое, но с другим интерфейсом, на мой взгляд более простым и удобным. Плюс поддержка плагинов, с которым можно легко поток I/O зашифровать, перенаправить через цепочку прокси, etc.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории