Re: in-order delivery

2006/3/6, Peter Saint-Andre <stpeter <at> jabber.org>:
> It seems that ejabberd doesn't deliver stanzas in order.

Is this what you mean?
'It seems that ejabberd doesn't deliver response stanzas in the same
order than the request stanzas were sent to him.'

>From what I understand, this subject is similar to HTTP in this sense:

1. HTTP 1.1 introduced several new features over HTTP 1.0, being one
of them 'request pipelining'. [1]

2. Request pipelining: allows the client to send multiple requests at
the same time' [2], 'send multiple requests without waiting for each
response' [4]

This part is similar on XMPP, since it allows the client to send
several requests, even before receiving the response to the first of
them.

3. In-order responses to the requests: 'The requestor then waits for
the responses to arrive in the order in which they were requested.'
[3], 'A server MUST send its responses to those requests in the same
order that the requests were received.' [4]

So, HTTP 1.1 REQUIRES servers to send responses in the same order of
the requests. Some clients interpret XMPP that way, but ejabberd
doesn't.

One solution to clarify XMPP ambiguity is to make XMPP interpretation
similar to HTTP, and requesting non XMPP 1.1 compliant servers to
apply that restriction.

Let's see if that restriction would be beneficial or not. A 'longer
pipeline can actually cause user-perceived delays if earlier requests
take a long time to complete' [3]. It is common sense that if we
restrict the server to send responses in the same order the requests
were received, long processing requests will slowdown the flow. I
don't know why HTTP 1.1 authors required this restriction when
writting the RFC, and if they would like to remove it today in HTTP
1.2.

I don't know if it's easier to implement clients with the
responses-in-request-order restriction or without it. It seems some
(maybe most) clients were implemented without that restriction in
mind, and hence work perfectly with servers of any kind, and even in
the presence of errors on the order of responses.

I don't know either if servers are easier to implement with that
restriction or not. I guess that highly concurrent servers like
ejabberd will need to add additional code to implement such a
restriction.

Summarizing: another solution to the XMPP ambiguity is to remove the
restriction of responses-in-request-order. This would allow servers to
decide themselves how they want to answer. Most clients would benefit
from their already efficient implementation that doesn't require that
restriction. The worst part would go to those clients that interpreted
that XMPP requires in-order restriction.

What solution is beneficial?

> In particular,
> I've had several people complain that at jabber.org their clients are
> receiving presence before the roster. It's possible that this needs to
> be clearer in RFC 3921, but IMHO it is best to deliver presence only
> after delivering the roster.

As a temporal work-around for those clients, maybe it's easy to
implement initialroster-before-presences on ejabberd.

> Thoughts?

My spider-sense alerts me that responses-in-request-order is a
restriction from the past that should be avoided. (I acquired this
sense after a 9 months development of an emulator in C/SMPL to compare
the performance of HTTP/1.1 pipelining and persistent connection
features over HTTP/1.0. The results were not published on any congress
since they were already common knowledge even on the time, but I
presented the research work as an end of degree project, in spanish
only).

[1] http://en.wikipedia.org/wiki/Http
[2] http://en.wikipedia.org/wiki/HTTP_pipelining
[3] http://www.mozilla.org/projects/netlib/http/pipelining-faq.html
[4] http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html
[5] http://en.wikipedia.org/wiki/Spider-Man#Spider-sense