[Standards-JIG] UPDATED: JEP-0030 (Service Discovery)

Ian Paterson ian.paterson at clientside.co.uk
Tue Mar 16 21:39:23 UTC 2004

Ian Paterson wrote:
> > If a MUC server has 1000 rooms and an average of 10
> > users entering each room per hour. If each MUC client
> > allows its user to choose from a list of room names
> > and occupants before he/she enters a room. Then that will
> > result in a total of 10 thousand disco#items requests,
> > plus 10 million disco#info requests per hour!

Peter Millard wrote:
> My client may get a list of rooms, and send a  disco#info
> to each room (1001 IQ roundtrips), but it surely should never
> query further. In addition, the server would probably not ALLOW
> me to get a list of users in each room if I'm not in the room.

I agree. But the example didn't suggest the client would get the list of
users. The 10 million total IQ roundtrips per hour are the result of the
1001 IQ roundtrips per client you mentioned.

1000 rooms * 10 users entering each room per hour
   = 10 000 disco#items requests per hour

10 000 disco#items * 1000 rooms
   = 10 000 000 disco#info requests per hour

> Clients just don't do this kind of thing in the real world (at
> least for MUC they don't).

Perhaps MUC isn't used for large text conferencing services today. But
companies (including Jabber Inc) are working hard to convince the major
European mobile service providers to adopt XMPP. IMHO chat rooms will be
important to them.

IMHO the JEPs must allow for a scale significantly larger than the one
described in my example (even if today's implementations don't). France is
not a big country, but right now more than 20 000 people are using France
Telecom's Web chat.

> So far in the real world, we have yet to see this happen. Jabber
> has always used the design rules of "solve the problems we know
> about, not the ones we don't."

This spring the major ISP in Portugal will migrate its public Web chat
service to MUC. The original motivation for doing this was to enable
compatability with XMPP IM services. Wouldn't it be nice if more and more
providers think the same way? :)

> In the Exodus browser, it ONLY fetches disco#info
> for each child entity if there are 20 items or less.

Good policy. :)

I understand that the "Denial of Service" in the example is (or at least
should be) impossible. My real point is that this very basic functionality
should be possible without the risk of DoS.

> So when I browse to ietf.xmpp.org, I only see the jids,
> not the fact that each one is a TC room.

Is that ideal?

> perhaps that service should use the jabber:iq:search protocol instead
> of providing drill-down capabilities via jabber:iq:disco.

Most JEPs only support Disco. ;) Of course we don't want two discovery

Unfortunately, as I understand it, Disco does not allow JIDs (including the
rooms of a single MUC service) to be structured (Example 6 only features
nodes that have the same JID). If it did, that would work very well - for
the MUC example at least.

- Ian

More information about the Standards mailing list