Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What is the state of power saving related XEPs which are critical for battery life on mobile? Looks like nothing is moving anywhere. For example XEP-0273 is still deferred:

http://xmpp.org/extensions/xep-0273.html

I'd worry about this even before anything else when it comes to XMPP on mobile, since otherwise your client can be a hungry monster eating up your battery in no time.



The main problem with energy saving are short-living NAT session in the "carrier grade" NAT systems deployed by mobile ISPs.

You need to ping the server aggressively to prevent a NAT timeout from killing your connection. On most networks, ping intervals of 15 minutes are sufficient, but some ISPs seem to be brain-dead enough to kill TCP connections even earlier, enforcing additional load on their own networks.

However, it is hard to make a proper guessing algorithm to estimate the time between ping messages, so most apps hard-code it. yaxim is using 15mins and hoping for the best. Xabber is working with 1min (or 30s, not sure), Google's cloud connection is using a similarly low interval.


How is IPv6 deployment going in the mobile networks? That could solve all these NAT problems.


Zero deployment on the networks I have access to. Also I would not be surprised if the carriers manage to break permanent connectivity there with stateful firewalls.


T-Mobile deploys IPv6 exclusively to Android devices with 4.4 (Kitkat): http://www.dslreports.com/shownews/TMobile-Goes-IPv6-Only-on...


I'm on the edge of my knowledge here, but your might look at the MQTT protocol [1]. Facebook uses this for Facebook Messenger [2].

MQTT, I believe can solve part of the power issue, as well others. However, I do not know how easy it is run XMPP over MQTT.

I've been evaluating this internally at my company as we explore M2M (machine to machine) communications in mobile.

[1] - http://mqtt.org [2] - http://mqtt.org/2011/08/mqtt-used-by-facebook-messenger


Interesting, but it requires an overhead of routing one high end protocol (XMPP) over another one. Not sure if it's the best approach. XMPP itself can offer mobile optimizations (like the XEP I brought above), but for some reason the whole thing seems stalled.


XMPP is XML, which is most probably sent over TCP. I think if you had a XMPP to MQTT gateway this might solve the "last mile" for XMPP and power.


It still looks more like a workaround rather than a straight solution. I.e. chatty nature of XMPP is masked / mitigated with MQTT. A proper way is really to reduce the chattiness of XMPP itself in cases when it's needed.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: