[ejabberd] Re: in-order delivery
mange at freemail.hu
Tue Mar 14 18:06:45 MSK 2006
"Peter Millard" <pgmillard at gmail.com> writes:
> ID attributes on iq elements are provided so that an entity can do
> async tracking of a request response transaction with-out having to
> block. This allows a client to possibly do other things (could be GUI
> operations, could be XML stream ops) while waiting for a response.
> I guess what I do not understand, is how are you interpreting this
> part of RFC 3920:
> 10. Server Rules for Handling XML Stanzas:
> Compliant server implementations MUST ensure in-order processing of
> XML stanzas between any two entities.
> The two entities in question in my examples are a full user jid
> (pgm at jabber.org/foo) and the server (jabber.org). Chatting with Alexey
> on Friday I found out that basically ejabberd uses different
> processing queues depending on the type of packet that is delivered.
> So if a presence packet comes in, it goes to queue A, if a roster
> packet comes in, it goes to queue B, if an iq:privacy packet comes in,
> it goes to queue C. Using this architecture, how are you complying
> with the in-order *PROCESSING* requirement of section 10? If queue C
> is not heavily loaded, it will clearly be processed before my presence
> packet in queue A.
In this particular case, it won't. ejabberd_c2s takes care to process
iq:privacy packets synchronously in incoming order. Generally you're
right, of course.
[OT: If the XMPP RFCs were written in Russian, we would already know
which is the correct interpretation of "process" (perfective vs
imperfective) ;) ]
JID: legoscia at jabber.cd.chalmers.se
More information about the ejabberd