Thanks for developing this XEP and trying to reduce handshakes. We are looking into using XMPP over radios (2400 .... 9600 bps) and were looking into using something similar to HTTP pre-binding (http://metajack.im/2009/12/14/fastest-xmpp-sessions-with-http-prebinding/) . Number of handshakes is currently one of the main argument against XMPP (when comparing XMPP and IRC). We have had best results with the old (legacy and less secure) Jabber NON-SASL standard (http://xmpp.org/extensions/xep-0078.html).
I fully support your approach: > When connecting to any server, it can first attempt to use > full pipelining. If that fails, it can simply reconnect without > pipelining. It can cache the failures. It would need to do this even > if the server indicates it can support pipelining, as the server may > be lying/buggy and e.g., might not support merging TLS negotiation and > XMPP data in the same TCP packet. Michael On Thu, Aug 11, 2011 at 3:46 AM, Waqas Hussain <[email protected]> wrote: > On Thu, Aug 11, 2011 at 2:28 AM, XMPP Extensions Editor <[email protected]> > wrote: >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: XMPP Quickstart >> >> Abstract: This document defines methods for speeding the process of >> connecting or reconnecting to an XMPP. >> >> URL: http://www.xmpp.org/extensions/inbox/quickstart.html >> >> The XMPP Council will decide at its next meeting whether to accept this >> proposal as an official XEP. >> >> > > Example 1 doesn't take things to their logical extreme. > > STEP 1 can be merged with the TLS ClientHello message. > STEP 4 can be merged with the server's TLS Finished message. > STEP 5 can be merged with the client's TLS Finished message. > STEP 9 can be merged with STEP 7. > If the server handles it just right, STEP 8 and 10 could be merged > into one TCP packet (in response to 7+9). > > If you are not negotiating TLS in the middle, you can start a stream, > do PLAIN or ANONYMOUS login, request roster, set presence, join a > chatroom, and send messages, all in the first TCP packet. This makes > legacy SSL somewhat attractive. The same can be done with BOSH, if you > skip the stream restart on SASL (which virtually all existing clients > do?). > > Moving on... > > Does the client even need to pay attention to the pipelining stream > feature? When connecting to any server, it can first attempt to use > full pipelining. If that fails, it can simply reconnect without > pipelining. It can cache the failures. It would need to do this even > if the server indicates it can support pipelining, as the server may > be lying/buggy and e.g., might not support merging TLS negotiation and > XMPP data in the same TCP packet. > > Looking at Example 1 closely, the client pipelined <starttls/> before > looking at the stream feature, so what's the stream feature for? Is > the client expected to not pipeline unless it has seen the feature in > a previous connection to the host? Why? Given that the failure case is > harmless, and that pipelining might work on many existing servers, why > wouldn't it want to use it on first connect? Would using it violate > any specification? > > -- > Waqas Hussain >
