Комментарии 12
Хорошее исследование. Автор — молодец!
+4
Вот за что люблю Perl, так за множество готовых решений. Небольшое исследование CPAN и всё, что угодно можно сделать за кратчайшее время.
+5
Спасибо. С удовольствием еще почитаю про событийное программирование в примерах)
+1
Сервис временно недоступен. Попробуйте повторить запрос позднее.
Хабраэффект
Хабраэффект
+1
Скорее всего, был обрыв соединений icq. Они восстанавливаются не сразу, а в течение 5-15 минут — можно посмотреть в исходниках :)
0
К тому же, надо сильно постараться чтобы уронить сервис — асинхронная отработка запросов и лимит 1 запрос на проверку в 15 секунд с 1 айпи не дадут загрузить все 10 icq-соединений. После запроса icq-соединение помечается как недоступное на 3 секунды, для предотвращения его использования для следующей проверки (если этого не делать, то при слишком быстрой посылке сообщений сервер icq может отключить за флуд)
0
:)
Вы сказали, что пробовали использовать 3 ICQ модуля из CPAN (я так понимаю это Net::OSCAR, Net::AIM и что-то связанное с AOL, там туча библиотек), у меня как-то стояла такая же задача, тоже ни один из модулей не подошел, что бы вы посоветовали для написания простейшего ICQ бота (прием-отправка сообщений)?
Вы сказали, что пробовали использовать 3 ICQ модуля из CPAN (я так понимаю это Net::OSCAR, Net::AIM и что-то связанное с AOL, там туча библиотек), у меня как-то стояла такая же задача, тоже ни один из модулей не подошел, что бы вы посоветовали для написания простейшего ICQ бота (прием-отправка сообщений)?
0
Насколько знаю, Net::Oscar рабочий. В принципе, можно использовать мой модуль — там реализована отправка сообщений, и колбэк на принятое сообщение (но нет разбора этого сообщения и выдирания текста сообщения из пакета). При желании можно допилить до полноценного icq-клиента и выложить на CPAN, я этим вряд ли буду заниматься
0
Скажите, как решается у Вас проблема с «автоподъёмом» демона? Решают ли эту задачу используемые библиотеки?
0
Спасибо, попробую покапать в эту сторону.
0
О, приятно видеть, что я не зря выкладывал на CPAN модуль FCGI::EV, он уже кому-то пригодился. :)
Я тоже экспериментирую сейчас с неблокирующими веб-приложениями. Одна из причин — избежать сложного управления процессами (то, что кое-как пытается делать FCGI::ProcManager — но если почитать APUE Стивенсона, то становится ясно, насколько этот модуль наивно написан… так что я бы его никому не рекомендовал использовать в продакшне). Чтобы избежать блокирования при обработке CGI-запросов часть задач веб-приложения выносится в отдельные сетевые сервисы. Получаем сервис-ориентированную архитектуру, отличное масштабирование, и упрощение разработки сложных систем.
По поводу AnyEvent — идея, безусловно, хорошая. Но дело в том, что мы достаточно серьёзно потестировали разные реализации event loop на CPAN, и обнаружили, что реально пользоваться можно только модулем EV — остальные либо глючат, либо грешат утечками памяти, либо тормозят, либо дико переусложнены. А event loop — это сердце приложения, там таких проблем быть не должно! Поэтому я свои модули пишу не на AnyEvent, а на EV.
Кстати, в качестве альтернативы AnyEvent::Handle можете глянуть мой IO::Stream. По сути он делает то же самое, но с другим интерфейсом, на мой взгляд более простым и удобным. Плюс поддержка плагинов, с которым можно легко поток I/O зашифровать, перенаправить через цепочку прокси, etc.
Я тоже экспериментирую сейчас с неблокирующими веб-приложениями. Одна из причин — избежать сложного управления процессами (то, что кое-как пытается делать FCGI::ProcManager — но если почитать APUE Стивенсона, то становится ясно, насколько этот модуль наивно написан… так что я бы его никому не рекомендовал использовать в продакшне). Чтобы избежать блокирования при обработке CGI-запросов часть задач веб-приложения выносится в отдельные сетевые сервисы. Получаем сервис-ориентированную архитектуру, отличное масштабирование, и упрощение разработки сложных систем.
По поводу AnyEvent — идея, безусловно, хорошая. Но дело в том, что мы достаточно серьёзно потестировали разные реализации event loop на CPAN, и обнаружили, что реально пользоваться можно только модулем EV — остальные либо глючат, либо грешат утечками памяти, либо тормозят, либо дико переусложнены. А event loop — это сердце приложения, там таких проблем быть не должно! Поэтому я свои модули пишу не на AnyEvent, а на EV.
Кстати, в качестве альтернативы AnyEvent::Handle можете глянуть мой IO::Stream. По сути он делает то же самое, но с другим интерфейсом, на мой взгляд более простым и удобным. Плюс поддержка плагинов, с которым можно легко поток I/O зашифровать, перенаправить через цепочку прокси, etc.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Пример построения неблокирующего веб-приложения