- комментарий 0:
From: kmeaw
Date: 2020-12-08 16:43:50Z
> но из-за желания использовать мобильные
> устройства, он тоже отпадает, ибо, насколько понимаю, нету для мобильных
> ничего нормально работающего, кроме централизованной проприетарщины
У меня отлично работает Conversations (eu.siacs.conversations).
Поддерживаются все нужные мне фичи: архив на стороне сервера,
возможность загружать и отправлять видео и изображения прямо из клиента
с E2E-шифрованием перед HTTP-upload/download. Вроде бы ничего
проприетарного он меня использовать не заставляет, работает с любыми
XMPP-серверами.
В этом клиенте мне не хватает только возможности легко понимать статус
собеседника (offline/away/online) без необходимости временно прятать на
экране ростера все offline-контакты. Похоже, что это общая тенденция во
всех мессенджерах - работать в предположении, что собеседник абсолютно
всегда online, ведь у него есть всегда работающий мобильный клиент.
До Jabber я пытался использовать IRC для тех же целей, но неудобна
необходимость держать bouncer или использовать нестандартизованные
расширения протокола, чтобы сохранялись сообщения для меня, когда мой
клиент offline.
- комментарий 1:
From: Sergey Matveev
Date: 2020-12-08 17:05:01Z
*** kmeaw [2020-12-08 19:34]:
>У меня отлично работает Conversations (eu.siacs.conversations).
Почему же тогда во всех случаях на любых ресурсах при любом обсуждении
IM-ов все всегда говорят что XMPP на мобильных устройствах отвратительно
работает? Не, я понимаю что всегда и везде будут люди которые на любую
тему будут говорить что "оно не работает", но на тему XMPP я
действительно никогда на практике в живую не видел чтобы люди его
использовали (на мобильных устройствах).
И я думал что действительно это всё так, потому что клиенту постоянно
нужно по TCP общаться с сервером, тогда как централизованные IM-ы сами
"пнут" мобильное устройство (push-уведомлением) когда есть какое-то
событие на которое нужно реагировать. А с нормальным native решением,
без third-party на которое выносится часть работы клиента, оно не даст
"спать" (жить в энергосберегающем режиме) мобильному устройству. Я очень
давно ещё на первом OpenMoko ставил Jabber (когда ещё даже EDGE не факт
что использовался) и оно работало только когда смартфон не спит, и мне
заряда хватало чтобы из дома добраться до института, после него до
работы, а дальше сразу же на зарядку.
Сейчас оно уже приемлемо эффективно может работать? Или у вас просто нет
требования приличного времени работы (лично у меня не было), а у других
есть, вот они и говорят что XMPP/IRC/whatever неюзабельны? Я слабо
разбираюсь в мобильных технологиях, но во время обсуждений на работе,
мне подтвердили что нормально по времени они могут жить когда почти всё
время спят, чего чисто технически нельзя сделать с "обычными"
классическими TCP программами долгоживущими. И поэтому все старые добрые
решения для IM чисто технически не приживаются из-за энергоёмкости.
>До Jabber я пытался использовать IRC для тех же целей, но неудобна
>необходимость держать bouncer или использовать нестандартизованные
>расширения протокола, чтобы сохранялись сообщения для меня, когда мой
>клиент offline.
Ну это я считаю наоборот плюсом. Человек не в online -- значит и не надо
ему писать. IM это IM -- это real-time общение. Если человек не в
online, значит не хочет общаться или ещё не на связи. Нужно доставить
сообщение -- отправляем через email и, когда человеку удобно, тогда он и
выйдет на связь и прочтёт. А возможность сохранения сообщения это и
сразу всё усложняет с технической точки зрения и из-за этого люди
начинают IM-ы использовать как email какой-то. Есть неудобство когда
связь плохая и происходит отключение от сервера, но что ж поделать,
бывает, не сложно и повторить пропавшие сообщения, как это люди делают
при обычной голосовой real-time связи.
- комментарий 2:
From: kmeaw
Date: 2020-12-08 23:40:02Z
> потому что клиенту постоянно
> нужно по TCP общаться с сервером, тогда как централизованные IM-ы сами
> "пнут" мобильное устройство (push-уведомлением) когда есть какое-то
> событие на которое нужно реагировать
Но ведь телефон каким-то образом получает push-уведомления. Не знаю, как
именно, у меня этот компонент не установлен, но вероятно прошивка
постоянно держит соединение с каким-нибудь сервером Google и ждёт оттуда
сообщений.
Чем это отличается от постоянно запущенного клиента, который заставляет
телефон просыпаться с некоторой периодичностью и проверять наличие новых
событий на сервере? Не знаю, разве что там, что в случае использования
централизованного механизма push-уведомлений на телефоне будет ровно
один такой пробуждающий телефон сервис, а различных мессенджеров у
типичного пользвателя может быть с десяток. Получается, что у меня
вместо централизованного сервиса от Google заряд аккумулятора тратит
XMPP-клиент.
> Или у вас просто нет требования приличного времени работы
…
> а у других
> есть, вот они и говорят что XMPP/IRC/whatever неюзабельны?
Особых требований к автономности у меня действительно нет, но телефон
(Motorola G5S) часов 40 работает. Возможно как раз благодаря
отсутствию Google Play сервисов и почти постоянной IPv6-связности (у
XMPP-сервера она тоже есть, а значит можно не делать keepalive для NAT и
реже будить телефон, держа долгие TCP-сессии). Не исследовал этот
вопрос, потому что меня устраивает, как всё работает сейчас.
При настройке сервера я включил
https://xmpp.org/extensions/xep-0357.html, но, скорее всего, на моём
телефоне это никак не отразилось. На iOS-клиентах (по крайней мере
ChatSecure) похоже, что эта фича работает - когда я пишу человеку с
таким клиентом в offline, то у неё появляется системное уведомление, что
пришло новое сообщение, и при переходе по нему просыпается XMPP-клиент,
переводя пользователя в online. Насколько я знаю, Apple ещё более
агрессивно "усыпляет" фоновые процессы для экономии заряда, чем Android,
и реализовать такой механизм без использования централизованных
push-уведомлений от поставщика мобильной ОС невозможно без jailbreak.
> Человек не в online -- значит и не надо ему писать.
offline-сообщения удобны, чтобы инициировать IM-сессию. Человек перейдёт
в online и если увидит, что я тоже online, то мы сможем начать какой-то
процесс, для которого важно real-time общение.
Можно, конечно, писать в почту "зайди в IRC, надо обсудить такой-то
вопрос", но не просто же так в том же IRC придумали MemoServ и
bouncer, реагирующий на highlight.
- комментарий 3:
From: Sergey Matveev
Date: 2020-12-09 08:59:14Z
*** kmeaw [2020-12-09 02:34]:
>Но ведь телефон каким-то образом получает push-уведомления. Не знаю, как
>именно, у меня этот компонент не установлен, но вероятно прошивка
>постоянно держит соединение с каким-нибудь сервером Google и ждёт оттуда
>сообщений.
Мне когда-то давно говорили что push-сервер обращается как-то к сотовому
оператору и он по GSM(/UMTS/whatever) каналу будит устройство (типа wake
on LAN). GSM чип то никогда не спит, но может дёргнуть основной
процессор, который уже включившись соединиться с сервером.
Вот тут упоминается про это:
https://stackoverflow.com/questions/17423782/send-push-notifications-to-ios-android-on-closed-wifi-nework-no-internet-connec
The reason why GCM can keep the power drain low is because of
special hooks for mobile data connections within the OS and chipset,
such that the CPU can power down while retaining an open socket
connection to the push server, where incoming packets from that
server will wake up the device. This is not available for WiFi.
Но что-то больше информации на эту тему (подтверждения этой темы) я не
нахожу бегло.
>Чем это отличается от постоянно запущенного клиента, который заставляет
>телефон просыпаться с некоторой периодичностью и проверять наличие новых
>событий на сервере?
Если спящий CPU и hook-и в коммуникационном процессоре не правда, то
тогда ничем не отличается, ну разве что более частым переключением
контекста CPU между приложениями, периодично общающимися с сервером.
>Насколько я знаю, Apple ещё более
>агрессивно "усыпляет" фоновые процессы для экономии заряда, чем Android,
>и реализовать такой механизм без использования централизованных
>push-уведомлений от поставщика мобильной ОС невозможно без jailbreak.
Ага, тоже слышал про такое. Я и сделал вывод что рассматривать мобильные
устройства нельзя как обычные компьютеры. С одной стороны в них такой же
сетевой стэк имеется, но с другой стороны этим всем по старинке нельзя
пользоваться из-за этих экономий питания. Хотя если бы хватало
устройство пускай даже на сутки, то и так нормально и сойдёт -- люди и
так постоянно везде и всюду заряжают свои устройства и ходят с
powebank-ами и что один, что два или три дня роли, по моему, уже не так
играют.
>offline-сообщения удобны, чтобы инициировать IM-сессию. Человек перейдёт
>в online и если увидит, что я тоже online, то мы сможем начать какой-то
>процесс, для которого важно real-time общение.
Когда этот человек будет в online, то вы возможно уже уйдёте в offline
:-) У меня не раз так было. В итоге проще было бы написать/обсудить
сразу вопрос по почте, чем ждать когда же оба собеседника будут в online.
Но это уже тема сетевого этикета, этикета общения в целом, а не вина
технологий, конечно же. Просто они, как и деньги, быстрее
показывают/открывают негативные черты, расхлябывают людей. Поэтому я и
считаю что такие, действительно, небольшие неудобства, но идут на благо :-)
>Можно, конечно, писать в почту "зайди в IRC, надо обсудить такой-то
>вопрос", но не просто же так в том же IRC придумали MemoServ и
>bouncer, реагирующий на highlight.
Частично согласен. Но то что "можно сделать" -- не значит что это "нужно
было делать". Есть же даже статья/высказывание "Not Implementing
Features Is Hard", которую я бы отнёс к этой теме.