Pull to refresh

Comments 36

А почему не в почту? Синхронизировать историю нескольких icq (работа/дом/мобильник) сложнее чем почтовый ящик.
Идея скорее не в сборе истории, а в мгновенной нотификации (почти смс получается).
Почта не всегда доставляется мгновенно, да и в случае какого-нибудь прорыва может сильно заспамить и провайдер закроет порт. Тем более мне не нужно хранить историю, она вся хранится на сервере вместе с дампами ошибок, здесь мне нужно просто узнать о самом факте возникновения ошибки.
Ну т.е. смс все равно удобнее будет?)
Ну, за смс и платить нужно. Не мало.
Я кстати для нотификаций воспользовался услугой от "SMS to e-mail/e-mail to SMS". Быстро и удобно. Правда есть лимит 100 sms в день.
Оффтоп:
Да, кстати об смс. У mail.ru есть сервис «уведомление на смс о новых письмах»(с довольно гибкими настройками). Итого, шлем себе на мыло уведомление, а оно приходит на смс. Тоже как вариант получается.
Кстати не так давно у меня была рабочая библиотека под делфи для отправки смс через агент mail.ru, самое главное она стабильно работала, хотя и с некоторыми ограничениями по частоте отправления, но я реально думал построить бота на ее основе, пока не узнал что с недавнего времени мейлрушники прикрыли возможность отправки SMS для сторонних клиентов, вот такая печаль.
Хорошая реализация. На практике, как мне кажется, если важна скорость, то лучше sms. Если скорость не важна, то почта.
SMS дороже, если использовать нормальный шлюз, да и насчет скорости большой вопрос, ICQ сообщения доставляется за секунды, а вот смски порой минутами в очередях у операторов стоят.
почта на тот же гугл приходит моментально в связке с телефонов с ms exchange (почти все нокии на симбе, например) или сразу гуглофон — теже смс, только с кучей инфы и дешевле
Почта приходит и почта уходит немного разные вещи, какой бы шустрый не был гугл, если на нашем сервере собралась очередь из писем на отправку, то он бессилен. Но согласен, в плане реализации оповещение на почту в разы проще.
можно отдельный демон (в вашем случае служба) под это дело или какой то http шлюз (хотя изврат конечно)
ну и с таким же успехом сервер может быть заддосен и на смс/icq шлюз не уйдет сообщение — остается только реальное подключение телефона к серверу — но тут смска может встать в очередь у оператор
в общем в каждом варианте есть риски… мне пока хватает майла, благо с сервака никто ничего не шлет (10-15 писем в день не забьют очередь на отправку)
«XXX: Новый сотрудник устанавливал бота для аськи на сервер. Рассылать сообщения о критических состояниях. Например температура поднялась, или упс перешел на батарею.
XXX: Сегодня аську сервера взломали! От сервера мне пришло сообщение „Приветик! Глянь мою фотку без одежды. Как тебе?“ Моя в шоке…
XXX: Очевидно я должен увидеть там фото процессора, не прикрытого кулером, или что там у серверов считается за интим?
ZZZ: ага, и на фото должны быть видны потекшие кондеры ;)
XXX: В совсем уж развратной версии — на фото должен быть виден голый процессор, измазанный белой термопастой...» (с) bash.org.ru
это и есть вы? =)
Нет, я пока только программные части мониторю, до аппаратных пока не дошел)
А как решается проблема с лимитом подключений? Не сталкивались? За статью спасибо)
Имеется ввиду когда сервер ICQ начинает блокировать подключения после обрыва связи? Если да, то такой проблемы у меня не было, но на этот случай имеется прогрессивный таймаут при реконнектах, так что рано или поздно бот с сервером свяжется.
Уважаемый автор, а можно боле развернуто написать, для чего и почему был использован MQ-сервер?
Какая в нём практическая польза, которую нельзя было получить без него?
Основная польза в том, чтобы не привязывать бота к определенной платформе, при использовании брокера совершенно не важно какое приложение генерирует баг-репорт, будь то PHP скрипт в он-лайн части или же десктопное приложение на Delphi/C#/.NET, механизм взаимодействия с ботом будет единым — просто отправить сообщение в очередь на MQ. Еще один плюс — при большом количестве генерируемых сообщений можно запустить одновременно несколько ботов, а распределением заданий между ними будет заниматься ActiveMQ. Также можно в плюсы занести возможность хранения сообщений при невозможности их мгновенной отправки, но в рамках данной темы это не очень актуально.
Как любят говорить в нашей компании «Так сложилось исторически», у всех сотрудников есть ICQ, протокол стабильный и проверенный временем, а поднимать локальный джаббер-сервер и включать его в эту и без того многозвенную схему как то не очень хотелось. Хотя ХМРР вполне достойная альтернатива и, возможно, кому-то будет удобней использовать именно этот протокол.
О стабильности наслышаны, да. *Сарказм*
Похоже, что фразу «Так сложилось исторически» любят в каждой компании :)
вот уж точно, у нас та же байка =)
неубедительные доводы. ICQ — стабильный и проверенный временем? Ну если не брать во внимание периодические падения (не каждый месяц, но всё же), проблемы с кодировками (вы сами об этом упомянули), отсутствие гарантии неизменности протокола, то да.
Jabber-сервер можно свой и не поднимать — есть полно готовых. Ну вот хотя бы google talk.
2-3 падения в год для меня не фатально, все таки не на АЭС работаю, проблемы с кодировкой возникли после введения ActiveMQ как промежуточного звена, напрямую все прекрасно отправляется безо всяких преобразований. Неизменность протокола это да, проблема, но обычно ее довольно быстро решают разработчики сторонних библиотек.
Я не пытаюсь сказать что ХМРР никуда не годится и ICQ спасет мир, просто завязать это все на аську лично для меня было проще, если бы у нас в компании все работали на mail.ru агент, я бы написал бота на его протоколе.
Скорость с использованием mysql не падает, в сравнении с KahaDB?
Если честно, то я не проверял, при моей нагрузке это и не понять. Изначально мускл я использовал для того, чтобы наглядно видеть что работает сохранение сообщений, так как с этим были некоторые трудности.
Немного про кодировки. Вы в тексте xml-сообщений явно указываете «windows-1251», а потом перекодируете в utf-8. При этом xml становится юникодным, а заголовок, разумеется, никак не меняется (iconv не для этого). Вот отсюда у вас и пляска с бубном вокруг кодировок. Уберите нафиг encoding из xml-заголовка (по-умолчанию он — utf-8; очень рекомендую почитать соответствующий стандарт).

Кстати, стоит проверить, какие рабочие кодировки у iconv — это тоже бывает важно и там дурацкие умолчания (по крайней мере, были).
Я пробовал и убирать это из заголовка и принудительно вписывать туда UTF-8, сейчас еще раз это проверил — не выходит, если скармливать XML напрямую боту, то никаких плясок не нужно, но если отправлять его через брокер, с этим сообщение происходит что-то непонятное и я только экспериментальным путем смог установить последовательность перекодировок которая выдала нужный результат. Но возможно я что-то упустил и есть более простой вариант решения этой проблемы.
Простите, пробовать и понимать, что происходит — сильно разные вещи. У вас рабочие кодировки iconv какие? На что именно матерится брокер? Какой именно брокер?
Имеется ввиду iconv_get_encoding('all')? Если да, то по умолчанию все кодировки iconv «ISO-8859-1», но я выставлял их и в 1251 и utf-8. Брокер ни на что не матерится, он молча пишет в базу и также молча выдает, но вот начинаю припоминать что про кодировку MySQL я забыл, возможно она тоже приложила руку к этому. Брокер — Apache ActiveMQ.
iconv_get_encoding() можно вызывать без параметров (значение $type по-умолчанию — «all»). ISO-8859-1 это та самая Latin-1, из-за которой у многих проблемы и которая так же по-умолчанию установлена и в Mysql (не забудьте посмотреть кроме параметров сервера и соединения установки базы и таблиц).

В общем-то, я пытаюсь подвести вас к тому, что имеет смысл понимать, как и что должно работать, чтобы не делать лишнего и не получать из-за этого ненужных проблем.
mb_convert_encoding() + mysql_query('set names «encode»;')?
Sign up to leave a comment.

Articles