Regarding XEP-0301 at http://www.xmpp.org/extensions/xep-0301.html I have a mathematic formula for the bandwidth of XEP-0301 as follows:
> The biggest impact on bandwidth of XEP-0301 are as follows: > (1) Is key press intervals being preserved? (Natural Typing) (uses more > bandwidth) > Section 6.1.1 at > http://xmpp.org/extensions/xep-0301.html#text_presentation > Animation: http://www.realjabber.org/real_time_text_demo.html > (2) What transmission interval is being used? (shorter uses more > bandwidth) > Section 4.4 at > http://xmpp.org/extensions/xep-0301.html#transmission_interval > (3) Is XEP-0138 stream compression being used? (uses less bandwidth) > See http://xmpp.org/extensions/xep-0138.html > (4) Are you using an optimized XMPP server that keeps headers compact? > (i.e. eliminates a lot of XMPP payloads such as noarchive indicators or <x> > tags). This overhead is added by Google Talk's servers and adds an > additional >100 bytes per <message> packet. > *Math Formula for Bandwidth of XEP-0301:* Here is a math formula for estimating the bandwidth of XEP-0301, for regular typing: X = H + (M + (K * i * N)) * C * (1 / i) Where: X = Average bandwidth, in bytes per second. H = Average TCP/IP packet header overhead. .........40 if using regular headers. .........10 if using header compression. (Average. This varies. Adjust appropriately for your network) M = Minimum <message> overhead in bytes, including <rtt> and one XEP-0301 action element. .........120 if highly optimized XMPP is used. (super compact jid's) .........200 if reasonably optimized XMPP is used. (public full jid's, infrequent extra payload) .........400 if Google servers is used. K = Number of keypresses per second. (Divide WPM by 12, so use K=5 for 60 WPM) N = Overhead per keypress. .........1 if Natural Typing is not used .........10 if Natural Typing is used (Average. This varies a bit, i.e. editing vs typing) i = Transmission interval between packets in seconds. Note: Variable is used twice in formula. .........Recommended value is between 0.3 to 1.0 C = Compression factor of XMPP .........1 if no compression used .........Less than 1 if compression used (XEP-0138 or TLS). Use a value of 0.2 for 5:1 ratio. _____________________ *Low Bandwidth XEP-0301 Scenario:* A compact packet from a deaf-optimized XMPP network with compact headers could be: <message to='u1152' from='u5168' type='chat' id='a1'><rtt xmlns='urn:xmpp:rtt:0' seq='1234'><t>HELLO</t></rtt></message> This is only 120 bytes to transmit five keypresses "HELLO" with no Natural Typing. 5 keypresses per second equals 60 WPM. Throw in TCP header compression and XEP-0138 stream compression and, presto, less than 50 bytes a second for ultra-efficient real-time text despite it being a XML based standard! Use TCP compression headers to reduce header overhead. No problem even for old-fashioned GPRS networks and slow Iridium Satellite networks! Variables: H=10, M=120, K=5, N=1, i=0.7, C=0.2 Formula: X = H + (M + (K * i * N)) * C * (1 / i) X = 10 + (120 + (5 * 0.7 * 1)) * 0.2 * (1 / 0.7) X ~= 10 + (120 + 3.5) * 0.2 * 1.43 X ~= 10 + 123.5 * 0.2 * 1.43 X ~= 10 + 35.3 X ~= 45 bytes per second! Rounded to the nearest byte, the low bandwidth XEP-0301 becomes an average of only 45 bytes per second for 60 words per minute typing in real time text at 0.7 second transmission interval! That is you're using compression, including TCP header compression _and_ stream compression. Small enough to squeeze over GPRS, dialup, and satellite. _____________________ *High Bandwidth XEP-0301 Scenario:* An example bulky packet with Natural Typing, is the one in Example 7.9: http://xmpp.org/extensions/xep-0301.html#full_message_including_key_press_intervals Notice how each keypress has some bulky payload data to encode the key press intervals. Throw in Google padding, the TCP header and bulky addresses, and you're approaching 400 bytes per packet. Let's assume you are keeping the transmission interval the same, at 0.7 seconds too. Let's assume you're not using any compression at all. Variables: H=40, M=400, K=5, N=10, i=0.7, C=1 Formula: X = H + (M + (K * i * N)) * C * (1 / i) X = 40 + (400 + (5 * 0.7 * 10)) * 1 * (1 / 0.7) X ~= 40 + (400 + 35) * 1 * 1.43 X ~= 40 + 435 * 1 * 1.43 X ~= 40 + 622 X ~= 662 bytes per second In this high-bandwidth scenario, 662 bytes per second is about 5 kilobits per second. Throw in some stream compression and use a variable C of 0.2, you can get it down to 164 bytes per second with Natural Typing. So you can still have Natural Typing at less than 200 bytes per second, if using a compressed stream to the XMPP server. * * *TIP: You could automatically use High Bandwidth mode for EDGE/3G/LTE networks, and adjust certain variables automatically for older GPRS networks. **This will produce high-fidelity real time text like http://www.realjabber.org/real_time_text_demo.html when the network speed is sufficient.* * * I hope this answers your question, Cheers, Mark Rejhon, deafie & computer programmer Author of XEP-0301
