@termonoid нужна инфраструктура пушей без гугла

@a1ba ну дак, селфхостед Gotify и погнали

@a1ba причем этот UnifiedPush может и с гуглом работать, приложение вообще ничего не теряет

@a1ba
Зачем нужна какая-то "инфраструктура"? Соединение открой до сервера и не закрывай, а сервер пусть пушит в него когда нужно.

@termonoid

@wire ну в принципе гугл так и работает :blobcatderpdeer:
Выигрыш, как и в случае с Gotify заключается в том, что в фоне висит не двадцать приложений, из которых два электрона, а одно сверхлегкое, которое будит получателей только при необходимости

@a1ba

@termonoid @a1ba
Приложение в любом случае висит в памяти или свопе, когда придут данные в сокет, то вызов epoll разблочится и из свопа приложение достанется. Держать 20 сокетов или один на keepalive-ах разницы нет почти.

@termonoid @a1ba
Keepalive даже нафиг не нужен, но можно выставить в 15 минут на всякий случай.

@wire @termonoid очень хотелось бы, но андроид так не работает.

Сервис висит в памяти всегда. А вместе с ним и весь жвм.

Учитывая как плохо пишут под андроид (лучше чем под вебню конечно), то этот сервис вместо того чтобы просто держать соединение, будет ещё какой-нибудь цикл крутить. Особенно чтобы сокет не сдох когда сеть переключится с мобильной сети на WiFi.

@a1ba @termonoid
Так это проблемы кривого кода, если он в busy loop крутится. Надо PR слать чтобы это исправлять, а не unifiedpush прикручивать. Особенно будет много толку, если все приложения будут через гуглосервис, а 3.5 через unifiedpush.

@wire @termonoid в проприетарщину PR не зашлёшь.

@wire это лучше, чем если эти 3.5 приложения будут держать постоянные соединения, ещё и пингуя другую сторону (а иначе коннект очень быстро отвалится)

@a1ba

@termonoid @a1ba
> а иначе коннект очень быстро отвалится

Вот это вообще неправда. Если его не закрывать специально на сервере и клиенте и не включать SO_KEEPALIVE, то не отвалится вообще никогда.

@wire это не сервера. Это мобильники. Они внешние IP меняют как одноразовые перчатки
Ну и как минимум серверу надо отслеживать отвалившихся клиентов, чтобы не держать зря соединение

@a1ba

@wire а ещё мобильники в 99% случаев за NAT, которому тоже не в кайф держать твое соединение бесконечно долго

@a1ba

@termonoid @a1ba
Отвалившийся клиент обнаруживается в тот момент, когда сервер спихивает в сокет данные и в ответ не приходит подтверждение. Если через таймаут подтверждения нет, то можно закрывать.

Если хочется закрыть потому что долго нет данных на уровне приложения, то можно об этом предупредить сообщением в сокет, и клиент переоткроет соединение если еще жив.

Keepalive на уровне TCP для всего этого не нужен.

@wire ок, сервер спихивает данные, не получает ответа. Но уведомление то надо как-то отгрузить! А телефон и не знает, что соединения больше нет!

@a1ba

@wire в идеальном мире, с идеальным коннектом да, нам не нужны Keepalive. Там даже TCP не нужен, можно по UDP швырять :blobcatderpdeer:
Но идеальное соединение и мобильник это непересекающиеся плоскости

@a1ba

@termonoid @wire про UDP: ну кстати необязательно.

После своих наблюдений с сотовыми сетями, я пришел к выводу что операторы на своей стороне что-то делают чтобы UDP все-таки доходил. С большим латенси, но не терялся.

Когда xash3d-fwgs портировали на мобилы, игроки с них держались на серверах дольше всех, даже в условиях "нахожусь в лесу в Сибири".
@termonoid @wire к дискуссии нерелевантно если что.

@a1ba они это не обязаны делать, поэтому лучше на такое не полагаться :blobcatgooglyshrug:

@termonoid само собой. Просто наблюдение. :)

Я даже скажу, что они и длинные UDP пакеты доставляют, а вот всратые WiFi роутеры дропают все что выше MTU.

@a1ba @termonoid
Скорее всего там один NAT на PGW из коробки настроенный производителем с учетом многолетнего опыта обслуживания всевозможных видов приложений.

А вот на Wi-Fi будет дичь с NAT-ом, действительно, потому что за ним может быть любой провайдер, в том числе посадивший юзера за 3 NAT-а, два из которых это роутеры уровня d-link.

@wire @termonoid ну да, это наверное и ответ почему длинные UDP сообщения доходили, до того как мы сделали фрагментацию
@wire @termonoid есть ещё и софтовые ограничения.

Знаешь почему Conversations и Husky держат открытыми уведомление о том что соединение висит?

Потому что иначе ОС прибьёт твой сервис. :)

@a1ba @termonoid
Стоковый андроид или lineageos не прибьет. Это баг прошивки если она убивает, нужно это и исправлять, а не эмулировать push-сервис гугла.

@wire нет, это не баг. Это намеренное ограничение. Хочешь жрать бесконтрольно батарейку в фоне - юзер должен быть в курсе. Если захочет, может скрыть эти уведомления

@a1ba

@termonoid @wire и это я ещё в Husky написал патч чтобы держать вебсокет.

Так-то там сервис который раз в 5 минут дёргает API и это вообще треш, который в реальности не работает.

@wire Android != Linux. Он вполне может выгрузить приложение из памяти, и разбудить его при получении уведомления

@a1ba

@termonoid @a1ba
Пусть выгружает в юзерспейсе если хочет, главное чтобы процесс Service оставил, заблоченный на сокет до сервера Matrix.

@wire @termonoid и попрощайся с мобила работала день-полторв
@wire @termonoid особенно когда так будет соединение будут держать не 1 приложение, а 15

@a1ba @termonoid
И что изменится? Ты шлешь 5 пакетов чтобы открыть каждое TLS-соединение, дальше можешь ничего не делать пока соединение не поменяется (IP-адрес новый не дадут, с Wi-Fi на сотовую сеть юзер не переедет и т.д.).

Sign in to participate in the conversation
Mastodon.ml

Русская нода социальной сети "Мастодонт", части Fediverse - всемирной федерации социальных сетей. Зона общения, свободная от рекламы и шпионажа, теперь и в России.