Looking at the spec I think we can have much better "quickstart" if we use Stream Management with very long timeouts for stream resumption. This would gives almost instant reconnection with far less traffic then the XEP proposes. I think our plan should be:

1. Improve/customize Stream resumption implementation to allow for a quick reconnection over longer timeouts - version 1.0

2. Then work on this XEP implementation to make our libs and clients compatible with other servers and our server with other clients - version 2.0

What do you think?

%kobit I agree - almost.

StreamManagement resumption takes place AFTER authentication. Quickstart is used between establishing of TCP connection up to resource binding. So my idea was to use quickstart as described in XEP but also in case of resumption - as opening of stream, TLS negotiation, ZLIB negotiation and authentication are common parts for initialization of stream and stream resumption.

Hm, ok then. I did not read all the details from the stream management XEP so I was not aware of this.

Now I am kind of disappointed with both XEPs, especially the stream resumption spec. Because it could be easily done in a more efficient way. Maybe I am wrong, but for a stream resumption a logical approach for me was something that is done for Bosh. Instead of authenticate each HTTP connection for each Bosh request, server and client exchange session ID as an authentication token sort of. This is would could/should be done for stream resumption to further speed reconnecting up. In such a case, maybe we should work on our own "quickstart" XEP or just customize stream resumption in such a way that we could skip authentication part and reconnect to existing session using session ID.

I would wait with "our own" quickstart as I've read that new XEP for SASL and authentication is being prepared.

However I prefer quickstart over something like in bosh due to security as using session id and passing it from client to omit authentication is rather not secure. And we still need to negotiate TLS and ZLIB, so there will be less performance improvement as TLS and ZLIB require round trips between client and server and this is slowest part. Also with new "improved" SASL there should be less round trips for authentication.

OK, agreed.

I've implemented pipelining support and tested it with our iOS client (development version) which also brings support for pipelining.

To enable this feature it is required to add @pipelining = true@ to @c2s@ section of a config file.

For now, this feature is supported only for the C2S connection manager to improve connectivity time for mobile clients.

As for WebSocket and BOSH:

• WebSocket on the PC/laptop users usually wifi and has low latency in which case pipelining will not reduce the time required for connection establishment.
• BOSH is used less often and is being replaced by WebSocket, which is faster and has less overhead.

Wojtek, could you look at the implementation and check if it is ok?

Checked and it looks ok.