Прощай net-im/psi - ты всегда был хорошим джаббер клиентом
slepnoga 23 марта, 2013 - 00:28
Если до 1 апреля сего года у psi не появится майнтайнер, который обновит и приведет в соответствие текущим реалиям ебилд psi - начнется процесс удаления ебилда из дерева.
P.S ебилд в дереве, но пока что без плюсов; Ждем, надеемся и верим.
»
- Блог пользователя - slepnoga
- Для комментирования войдите или зарегистрируйтесь
>Из моей практики они
>Из моей практики они совершенно замечательно работают. Хотя я в основном пользуюсь асечным шлюзом. И там работают и разного рода нстроения с допстатусами и отчёты о доставке
Как раз сегодня загнулся очередной :) За несколько месяцев третий на моей памяти. И, что печально, переход на новый шлюз это сотни геморроя. Начиная с нескольких сотен кликов подтверждения авторизации, процесс предполагает ручную чистку ростера от дубликатов и последующее переименование файлов истории. Приятно провел час :)
Ретроспективно наглядно видно, что лучше потратить время на установку собственного ejabberd + pyicqt. Глядишь, и скайпа прикрутить как-нить получится.
Да, и камень в огород пси — он, как и пиджин, непонятно как реагирует на проблемы со связью. Было зарегистрировано, что при переподключении VPN провайдера пси никак на это не отреагировал и продолжал «доставлять» сообщения — в никуда. Проприетарный скайп, в то же время, с ситуацией справился.
Beelzebubbie написал(а):>Из
Вродебы на данном сервере всё пока что стабильно работает. если что - ясно кого потыкать. У проблемы переезда, есть элегантное решение. Перед регистрацией на новом шлюзе нужно включить "автоматическую авторизацию контактов" и "автоматически открывать входящие сообщения". После этого моно зарегаться на новом транспорте и наслаждаться сотнями месаг летающих туда-сюда. :)
В Psi есть "подтверждения доставки"
>Вродебы на данном сервере
>Вродебы на данном сервере всё пока что стабильно работает. если что - ясно кого потыкать.
Ну я рассматривал не конкретный сервер. кроме того, с учетки на xmpp.ru я не могу пользоваться этим шлюзом. Проблема в том, что нужно быть готовым к переезду в любой момент.
>У проблемы переезда, есть элегантное решение
ну с окошками это поможет, однако вычищение старых контактов и «перелинковка» истории останется для ручек. Если контактов 10, то не проблема. Если их 400+ — проблема.
>В Psi есть "подтверждения доставки"
XEP-0079, XEP-0184? Имеется в виду «request/send receipts»? Я немного о другом — возможно, я чего-то не понимаю, однако меня дико удивляет, что сообщение вообще может вести себя как «отправленное» при отсутствии реального соединения с сервером. И вообще, мне кажется крайне нелогичным то, что IM клиент игнорирует проблемы с сетью. Уже не раз сталкивался, что при возникновении подобных проблем что пси, что пиджин _никак_ на это не реагируют. Никакой визуализации, никаких предупреждений. Конечно, в конце концов, по-видимому, происходит переподключение, но я ни разу этого не видел — стало быть, «время реакции» составляет сотни секунд. А в течение этого времени можно спокойно отправлять сообщения.
/
1. Проверить проблему на воспроизводимость с ещё некоторым количеством клиентов (два это только "совпадение", надо хотя бы три, а лучше для ровного счёта четыре).
2. Детально описать условия проявления бага (обязательно с достаточным описанием способа наблюдения, в идеале --- с приведением хотя бы одного способа воспроизведения бага последовательностью _твоих_ действий) и выложить для начала на форуме.
Насколько я понял, оно проявляется при переподключении на стороне провайдера (изменении параметров подключения при пренебрежимо малом времени неработоспособности канала), так?
3. Надлежащая проработка п.2 должна изрядно помочь в главном: в открытии соответствующего бага в родном трекере.
ЗЫ: И не стесняйся указывать условия, при которых оно критично.
:wq
--
Live free or die
Beelzebubbie
А ему информацию эту откуда брать? Через libastral? Проблемы с сетью - штука очень разноплановая, и если тебе нужно более-менее убедиться что сообщение реально дошло - есть тот самый XEP-0184. Psi нормально реагирует на проблемы с сервером, посредством обычных сетевых таймаутов, после чего начинает переподключаться. Как с технической стороны описать те самые "проблемы с сетью" ? Откуда клиенту знать что сети нет - постоянно накручивать трафик пингуя какимнибудь образом сервер? Получать сообщения от NM/Wicd/whatever ? Тот же Skype постоянно жрёт трафик когда он сети - p2p есть p2p, но даже там у меня бывают сообщения не доходят. Также, у меня одна из учёток настроена через http-poll и при пересоединении и длительных лагах сети сообщения всёравно дойдут. Разные клиенты, карные сети, разные ОС - всё это сильно влияет на результат.
Клиент должен контролировать
Клиент должен контролировать не наличие сети, а статус доставки: доставлено на сервер - ок, иначе предупредить что твою писанину видишь только ты сам.
например, в kopete видно те сообщения которые отправлены, но не доставлены до сервера.
_SerEga_ написал(а): Клиент
В XMPP-сетях реальна ситуация, когда ты доставишь своему серверу, а он дальше передаст, и оно например между 2мя серверами завянет. Или до клиента не долетит.
О чём и говорилось выше - в XMPP есть для этого несколько протоколов.
все это замечательно и
Все это замечательно и очевидно (по большей части), однако практические опыты показывают фундаментально неверное поведение. Кроме того, я употребляю «проблемы с сетью» не как синоним отсутствия соединения с конкретным сервером, а как его причину и надмножество. Про «посредством обычных сетевых таймаутов» гипотеза не подтверждается, что показывается ниже. Жрет трафик? И сколько же он таким образом сожрет? На рубль за месяц?
Вкратце опишу их:
опыт 1
вытаскиваем сетевой кабель и пишем сообщения. сообщения «отправляются», никакой реакции на невозможность доставки не обнаруживается (что _уже_ нехорошо). Светлый момент в этом только один — после восстановления подключения сообщения доставляются. Сети не было минуты три.
опыт 2 (проведен мною и Анархистом, поочередно, при схожих сетевых конфигурациях)
Переустанавливаем подключение к провайдеру (в моем случае на роутере переподключаю L2TP, у Анархиста ADSL'у делается ресет)
Пишем пару раз в минуту сообщения и глядим на реакцию. Реакции никакой. Попытка использовать Service Discovery не завершается успехом, но и не выдает ошибку. Через минуту интернеты есть, но ничего не меняется. Только через 15-18 минут psi наконец переподключается и, разумеется, ничего не доставляет из написанного (это отличие от первого случая я склонен объяснять сменой IP). Ошибок никаких тоже, с его точки зрения, не произошло. Скриншоты заверены.
Проблема налицо — факт доставки/недоставки сообщений никак не контролируется. Мне удивительно видеть, что в данном случае игнорируются даже базовые возможности TCP по контролю доставки пакетов (где Вы видели такие таймауты и чем может быть обусловлено в данном случае его значение, большее, чем полминуты?)
Наблюдения «из жизни». Поскольку мой провайдер считает, что инициировать несколько раз в день переключение VPN — суть хорошо, я довольно часто сталкиваюсь с тем, что сообщения приходят на андроида (подключенного по воздуху к тому же роутеру) бесперебойно и достаточно вовремя (андроидный клиент быстро соображает о необходимости переподключения), а вот на десктоп таки приходит не все. Судя по всему, в этом есть все же огромный плюс — я экономлю несколько КБ трафика в день на keep-alive, потому что мой клиент считает что это важнее пропущенных при приеме и доставке сообщений. Я один не согласен с
этим или все же нет?
Ранее использовавшиеся мной мультипротокольные клиенты под Win не обнаруживали такого любопытного поведения, были разве что нарекания на ложноотрицательную (изредка) реакцию на проблемы с соединением с сервером, индикация проблем присутствовала.
В окончание добавлю, что пару лет назад я делал простенький бот на xmpppy, рассылающий сообщения и использующий в том числе траспорты ICQ и MRIM — и никаких проблем с определением даже более сложных проблем с недоставкой сообщений через транспорт, не испытывал. Странно думать, что разработчики psi не в состоянии реализовать детекцию проблемы доставки и переключить статус в оффлайн после контрольного неудачного выстрела по серверу.
.
Стоит добавить, что на одной стороне был "тестовый"
net-im/psi, на другой --- "стабильный".Также помним, что проблема наблюдается не только с
net-im/psi, но с учётом комментария про копыто --- не везде.Ты не находишь, что обсуждения требований к IM в принципе и xmpp в частности (а заодно вопроса надлежащести качества реализации) было бы правильнее вынести в отдельную тему?
:wq
--
Live free or die
Beelzebubbie
Не "низко", а _высоко_.
Анализ базиса --- штука не только весьма дорогая.
Но если ей пренебречь и начать делать без предварительной разработки проекта, то ты рискуешь вместо поиска правильного ответа искать результат, оправдывающий затраты труда.
Концепт вечного двигателя в своё время был весьма популярен. Рудименты этой популярности встречаются и доныне.
Так что ни популярность, ни тем более существование не являются доказательством правильности.
Это не ответ на вопрос о логике отработки возврата _нескольких_ сообщений.
Зачем почтовый клиент сохраняет сообщение независимо от факта доставки?
Поле ввода у тебя одно.
Несомненно :)
Надо же тебя приучить сказав А хотя бы обозначить остальные буквы.
В данном случае: когда, как и в каком диапазоне целесообразно увеличение задержки переподключения?
Ты очевидно сравниваешь некоторую физическую реализацию файловой истории с идеальной проекций истории в БД.
И игнорируешь мои вопросы.
Сколько нужно?
И, отвечая на другую реплику: структура должна учитывать наличие у одного и того же человека нескольких учётных записей (в одной или нескольких сетях).
Про чятики тоже забывать нельзя.
Угу...
Лично мне здесь на ум приходит история с MUC в ICQ.
:wq
--
Live free or die
>Не "низко", а
>Не "низко", а _высоко_.
скорее — «не полемику, а демагогию». судя по результатам. :D
>Анализ базиса
не будем тень на плетень наводить. суть мультипротокольного клиента — сокрытие (зачастую ненужных) особенностей сонма протоколов. Единообразный подход к IM, если хочешь. Тривиальнее некуда.
>как и в каком диапазоне целесообразно увеличение задержки переподключения?
очевидно, это зависит от желания пользователя. Очевидно, что кратковременные сбои должны завершаться оперативным пересоединением, а при долговременных не нужно ломиться каждые несколько секунд.
> очевидно сравниваешь некоторую физическую реализацию файловой истории с идеальной проекций истории в БД.
Очевидно здесь другое — изначально такой формат (файлы, html/xml) истории был выбран без учета того, что он будет впоследствии активно использоваться самим приложением. Поэтому без смены формата реализовать более богатый функционал не удастся.
>Сколько нужно?
А существует некоторая опосредованная универсальная цифра? :D Вообще-то я говорил о недоступности поиска по атрибутам контакта, что является серьезным недостатком. IM-клиент это отнюдь не утилита для решения конкретной задачи — это инструмент, позволяющий решать множество вопросов, посему чем шире функционал и настраиваемость, тем лучше.
>MUC в ICQ
можно сколько угодно критиковать любые протоколы и их темные стороны — тем не менее, пока они широко используются, их поддержка необходима. Оппонент начинает склоняться к демагогии — обычно это признак скорого израсходования аргументов ;)
.
Намекаешь на то, что "Всякая сложная проблема имеет простое, очевидное, неправильное решение."? :)
Практически: выравнивание функциональности по самому убогому (на стороне которого может играть ТМО, и который извлекает из такого подхода выгоду сохранения статуса гегемона).
Даже без постановки вопроса о том, скова (что) нужно.
Действительно, тривиальнее некуда.
Начинать здесь надо с вопросов: какой функционал нужен и действительно ли его нельзя реализовать в рамках принятой модели.
Если сделать на шаг больше, то выяснится, что и БД не является панацеей.
Никогда им не пользовался и не испытывал потребности.
С точки зрения философии Unix ты несёшь откровенную ересь :)
Практика показывает, что склонение к нахождению в возражениях оппонента признаков демагогии обычно как раз указывает на острую нехватку аргументов.
также поздравляю с наступанием на благополучно заготовленную оппоненту растяжку :)
Фишка в том, что фича MUC _протоколом_ ICQ предусматривается.
Но практически её никто не пользуется, потому что реализована она (была?) только в родных клиентах (причины ты сам красиво озвучил), которыми по понятным причинам... мало кто пользуется.
Вообще плясать надо (особенно в случае многопротокольных клиентов) от списков необходимого/желательного/опционально функционала.
Про гугл талк сотоварищи полагаю крайне полезным рассмотрение вопроса степени совместимости с родителем (xmpp).
:wq
--
Live free or die
>Намекаешь на то, что "Всякая
>Намекаешь на то, что "Всякая сложная проблема имеет простое, очевидное, неправильное решение."? :)
_сложной_ проблемы здесь нет. я уже слегка устал повторять — но я описываю в основном уже где-то имеющийся функционал. И, к слову — отсутствие решения вообще слегка хуже его частичного наличия.
>…выравнивание функциональности по самому убогому
а с чего ради-то? откровенная ерунда. Что, если у протокола XXX нет Service Discovery, то мультипротокольный клиент почему-то не может это использовать в XMPP?
>Начинать здесь надо с вопросов: какой функционал нужен и действительно ли его нельзя реализовать в рамках принятой модели.
вернись на пару шагов назад и почитай развернутое, но лаконичное описание функционала и его 2х популярных реализаций.
>Никогда им не пользовался и не испытывал потребности.
тут и возразить нечего. соседский кот, например, не пользуется IM вообще — включим и его мнение в обсуждение?
>С точки зрения философии Unix ты несёшь откровенную ересь :)
c точки зрения здравого смысла и рассмотрения перспектив самосовершенствования — быть ортодоксом суть архивредно :D
Оппонент то забегает вперед телеги, то прячется обратно. То мультипротокольность есть «выравнивание функциональности по самому убогому», то «полагаю крайне полезным рассмотрение вопроса». Интегрально-конструктивное мнение у оппонента вообще наличествует?