In the previous post I had a look at the background keep-alive data traffic of messaging apps on my GrapheneOS device that do not use the Google Firebase Cloud Messaging (FCM) service for push notification. I’ve optimized my apps and servers to have keep alive timers of 5 to 6 minutes, which ensures that even aggressive NAT routers in the path do not kill the connections. So how do these values compare to Google FCM?
To compare, I made a Wireshark trace of the Wi-Fi traffic of an Android device on which the whole Google suite of apps and lots of other things are installed. In case you want to run the same test, here’s the Wireshark filter I’ve used to see only FCM messaging:
dns.qry.name == "mtalk.google.com" or (tcp.port==5228 && (tcp.flags.syn == 1 or tcp.flags.reset == 1))
The domain name used for push notifications is ‘mtalk.google.com’ and TCP port 5228 is used for the channel. In addition, my filter above focuses on the TCP SYN and RESET flags to show when a channel was established to the Google Cloud and taken down again.
I’m pretty sure Google has optimized FCM keep-alive as much as possible and it was nice to see that the keep-alive timer in my configuration was around 9 minutes. I didn’t see any TCP disconnects over many hours, so the NAT routers in my connectivity chain could handle this well. I am aware of other NAT routers elsewhere that have shorter keep-alive values after which they discard NAT mappings, which would indicate that perhaps FCM is adaptive. But that’s speculation. So yes, this is quite optimized indeed!