To monitor my personal cloud and get instant notifications of events of various sorts on my smartphone, I’ve been using Gotify for many years. As it is based on TCP, keepalive packets have to be sent to keep NAT gateways happy. At the beginning, Gotify did so at a rate of 10 seconds. Far too much to be power efficient on cellular networks, the radio channel remained active all the time. Based on my feedback, the the keepalive timer was made configurable. With some trial and error, I then established that the NAT gateways between my server and my smartphone can easily cope with TCP keepalives of 7 to 8 minutes. So that is my setting for many years now, and things work very reliably and efficiently.
So far so good. For a recent project I also needed an instant notification solution. Gotify could not do the job for this project, however, because messages being pushed out should be delivered to many anonymous recipients that should only have read-access to the queue, i.e. they must not be able to send messages themselves. Gotify is a personal messaging server and all clients require a login and can not only read but also write to queues. So I started looking for something else and came across Ntfy, another great open source messaging solution. It is far more feature rich than Gotify, which is both good and bad. For my project, however, it does offer read-only anonymous queue access, so I’m strongly considering it as an option. It’s easy to set-up in a Docker container behind a reverse web-proxy and the documentation is outstanding!
So while I was happy at first, I soon noticed that the TCP keepalive time is set to 45 seconds. Due to timeouts and other things happening in cellular networks, this means that the radio connection is also pretty much active for most of the time while the Android app is running, it only goes idle (LTE RRC Release) for a few seconds, before the next paging comes in due to the next keepalive packet. Not ideal at all. The screenshot on the left shows what is happening on the LTE air interface.
While I was glad to see an option to configure the keepalive timer (keepalive-interval), the documentation notes that the app will only tolerate keepalive periods of up to 77 seconds.
# Note that the Android app has a hardcoded timeout at 77s,
# so it should be less than that.
#
# keepalive-interval: "45s"Perhaps better than nothing but still far away from where I would like it to be, i.e. 7 to 8 minutes. Not sure if a ticket with the project to ask them to offer settings to change this would have a chance of success, but perhaps I should do it anyway?