On Thu, May 17, 2012 at 7:20 AM, fam...@xs4all.nl <fam...@xs4all.nl> wrote:
> mmm .. > I have tested on mobile networks in Netherlands.It has many failures by > provider T-mobile. Because quatity of GRPS or 3G are not very good. I have > agreed with Gunnar that it's not only specific sitaution. it's now known > isusse that capaction of mobile system is not good. > That is true, the capacity of many mobile systems are not good. That said, XEP-0301 is very capable of functioning over narrowband GRPS. Bringing this back on topic of Standards, there are many variables controlled by the user, by the XMPP server company and by the cellphone company: 1. Variables caused by XMPP server. When I snoop on the raw XMPP data transmitted to Google Talk, they add a lot of extra data that you can avoid if you run your own server. Some companies may set up their own server (on the public network) that avoids the extra XML that Google Talk adds to XMPP connections, such as noarchive elements and the <x/> element. People with control over server deployment, can also choose server infrastructure that supports compression (i.e. TLS or XEP-0138). 2. Variables caused by the network level. The selection of the low level network will also determine whether TCP/IP header compression can be done. Timeouts caused within the routing (i.e. routers, mobile networks, reception loss, etc) can also dictate extra bandwidth required by reconnections or keepalive traffic. 2. Variables caused by the end user. The user may type fast, or slow, more often or less often. The user may have a big buddy list, which adds more data. 3. Variables caused by the author/developer. The author may or may not decide to support stream compression, if the server supports stream compression. The developer may or may not decide to support Natural Typing (keypress interval encoding) The developer may choose a longer or shorter transmission interval. The developer may add or remove data from the XMPP transmission, optimizing for efficiency on non-essential updates Some companies that run a lot of components of the network (i.e. companies like Google and Apple) may actually have control over a lot of these variables (#1 and #3), and it is definitely possible to *reduce the bandwidth of XEP-0301 by more than 90% *for the same typing speed by the end user, while still complying fully with ITU-T Recommendation F.703 of usable real-time text (less than 1 second end-to-end latency) Yes, it is more work if you want to heavily optimize for the bandwidth, but the point remains -- it is possible! Thanks, Mark Rejhon
