[ejabberd] in-order delivery

Paul Vixie vixie at isc.org
Tue Mar 7 22:17:12 MSK 2006


# 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.

since in HTTP/1.1 a response does not include enough information to match
it against an outstanding query, other than by ordering.  in other words
if you pipelined some queries and then got responses back in random order
you would not know, in HTTP/1.1, which response went with what query.  in
xmpp that's clearly not the case.

# 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.

perhaps that's common sense, but it's not my sense.  when requests are
pipelined, the background work (either network I/O or disk I/O or computation)
can be pipelined, thus decreasing the inter-response-gap time even though the
time-to-first-response might remain somewhat constant.

# 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 suspect that they'd love to have some ability to answer asynchronously,
but they'd have to do this by acking requests in order and providing some
kind of deferred-entity-ID, and then answering requests out of order, giving
each with its entity-ID.  that would have been a much larger change from
HTTP/1.0 than the authors of HTTP/1.1 were prepared to contemplate.  i
suspect that if HTTP/2.0 were to be developed it would look more like XMPP,
in other words there would be no "line mode", just XML stanzas.  but we
digress.

that having been said, i agree with your conclusion if not your reasoning:

# 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?

i think that since most clients are working with ejabberd as things are, that
this restriction is not having any practical effect and CAN be removed.  i
think that since any client desiring to serialize its request/response flow
can do so by avoiding request pipelining, and that a server could theoretically
operate much faster without this restriction than with it, that this
restriction SHOULD be removed.


More information about the ejabberd mailing list