in-order delivery

It seems that ejabberd doesn't deliver stanzas in order. 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.

Thoughts?

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd

Re: in-order delivery

On Mon, Mar 06, 2006 at 01:49:52PM -0700, Peter Saint-Andre wrote:
> It seems that ejabberd doesn't deliver stanzas in order. 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.
> 
> Thoughts?

I think that in-order delivery means that if entity 1 sends two stanzas 1 and
2 to entity 2 then entity 2 receives the stanza 1 before stanza 2.

When server replies to iq request or sends presence updates it does deliver
completely another stanza. So I wouldn't expect that roster must be delivered
before presence in this case.

I think that it's better for client or server developer to think about two
different streams "stream from client to server" and "stream from server to
client" and not to expect them to be synchronized. (Except natural cases like
replying to iq request etc.)

--

-- 
Sergei 'TeopeTuK' Golovan

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

Re: in-order delivery

On Tue, Mar 07, 2006 at 10:41:25AM +0100, Badlop wrote:
> 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.

The essential difference between HTTP and XMPP is that in HTTP there are clear
request/response structure. XMPP does not have such a structure. For example
<presence/> and <message/> stanzas do not require any reply.

--

-- 
Sergei 'TeopeTuK' Golovan

Re: in-order delivery

* Peter Saint-Andre <stpeter <at> jabber.org> [2006-03-06 13:49:52 -0700]:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> It seems that ejabberd doesn't deliver stanzas in order. 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.
> 
> Thoughts?

It is not really in-order delivery (order preservation of message).
However, I agree with your point. It considerably simplify client
development to make such hypothesis.
This is not clear in the current standard (I might be wrong however),
that a particular order has to be matched on connect. From memory, it is
not totally clear when the client must send the roster demand, or even
if he must send it (Some clients on mobile are caching the roster to
limit bandwidth consumption).
It might be good to have some clarification on this point (Maybe in a
best practice JEP ? I like them).  

--

-- 
Mickaël Rémond
 http://www.process-one.net/

Re: in-order delivery

On Tue, Mar 07, 2006 at 04:45:35PM +0100, Mickael Remond wrote:
> * Peter Saint-Andre <stpeter <at> jabber.org> [2006-03-06 13:49:52 -0700]:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > It seems that ejabberd doesn't deliver stanzas in order. 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.
> > 
> > Thoughts?
> 
> It is not really in-order delivery (order preservation of message).
> However, I agree with your point. It considerably simplify client
> development to make such hypothesis.

I don't agree. At least in the example of roster and presence IMHO it's very
simple to store all received roster items and presences independently and
update visible roster on both types of events. (BTW, most clients that were
written in jabberd 1.4 times (Tkabber, JAJC, Psi, whatever) work fine with
ejabberd, so it's natural to do so.)

In my experience the only situation when I might need to get answer
in-order was the activating privacy list at startup. But here I have to wait
for answer before sending the next stanza because server could reply error to
me, and I have to react to this error, not just simply continue (which may
impose a security risk).

Re: in-order delivery

Le 7 mars 06 à 17:56, Sergei Golovan a écrit :

> On Tue, Mar 07, 2006 at 04:45:35PM +0100, Mickael Remond wrote:
>> * Peter Saint-Andre <stpeter <at> jabber.org> [2006-03-06 13:49:52 -0700]:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> It seems that ejabberd doesn't deliver stanzas in order. 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.
>>>
>>> Thoughts?
>>
>> It is not really in-order delivery (order preservation of message).
>> However, I agree with your point. It considerably simplify client
>> development to make such hypothesis.
>
> I don't agree. At least in the example of roster and presence IMHO  
> it's very
> simple to store all received roster items and presences  
> independently and
> update visible roster on both types of events. (BTW, most clients  
> that were
> written in jabberd 1.4 times (Tkabber, JAJC, Psi, whatever) work  

Re: in-order delivery

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

FW: Subgroups in Shared Roster

Hello,
	I am wondering if there is a way to setup subgroups in the
shared roster?  For example, if I have Employees and Supervisors, I
would like Supervisors to show as a subgroup of Employees, instead of on
the same level in the roster structure.  Is this possible?

Bryan

Re: FW: Subgroups in Shared Roster

2006/3/8, Bryan Barnes <Bryan.Barnes <at> verety.com>:
> For example, if I have Employees and Supervisors, I
> would like Supervisors to show as a subgroup of Employees, instead of on
> the same level in the roster structure.  Is this possible?

It's a client-side feature:
JEP-0083: Nested Roster Groups
http://www.jabber.org/jeps/jep-0083.html

Tkabber screenshots:
http://tkabber.jabber.ru/screenshots/0.9.6

> I am wondering if there is a way to setup subgroups in the shared roster?

I tested it with Tkabber and it works. I just need to set the group
name to Employees::Supervisors

--