[Standards-JIG] proto-JEP: Address lists

Michal vorner Vaner michal.vaner at kdemail.net
Wed Jun 7 21:35:45 UTC 2006


On Wed, Jun 07, 2006 at 10:37:56PM +0200, Carlo v. Loesch wrote:
> Michal vorner Vaner typeth:
> | Hm, thats maybe why jep-0033 allows limits on size of the list. And,
> | if he has a possibility to build a list of 100 people, what is use for
> | him? He sends one message and needs another 100.
> 
> Well okay, arbitrary limits look like a good idea, but that counts my
> company out as a potential user of this technology. We run those vip
> chat events with some ten thousand people all in a chatroom, with each
> of them receiving what's coming from the VIP and submitting questions
> to an appropriately sized team of moderators. This scenario works fine
> with PSYC and could scale to hundreds of thousands, but in Jabber using
> JEP-0033 we have not the faintest chance to make it.
> 
> Oh sure you can always try to solve things with huge centralized servers
> and immense processing power, but we prefer to have your average linux
> boxes distributed on the Internet. And that requires a pretty smart
> protocol.

If you remove the limit on your server, where the MUC is for the MUC
only, you can update the list by adding and removing people only. If the
people are on separate servers, the list update can go to only that one.
The main MUC server needs to remember the whole list unfortunately, but
it sends only as many out stanzas, as many secondary servers you have.
And I guess it is still possible, right?

You do not need to send the list again, you just need to send the
updates with the presence of person entering or leaving.

I will not try to persuade you, since I do not know the right
conditions. But I guess that, if you have one server for the MUC
component, it will be capable of taking it and just send single-stanzas
to the multicast component. The multicast component will multiply it for
other multicast components and these will have enough resources to
multiply them to the users, wouldn't them?

It would me something like this:
                                                client
                                                 /
                                 remote multicast -client
                                /               \
Master MUC ---- Local multicast                client
                                \
				 remote multicast - client
				                 \ 
						client

If I this would not work, I would really like to see where I made a
mistake.

> | And yes, if we are about to build a multicast principle everyone can
> | use, then yes, everyone can misuse. But it is the same with everything.
> 
> The way you design multicast lays the foundation for its spimmability.
> It's always nice to come up with new words.
> 
> | But that is not transparent. That is why it is not used. You would have
> 
> ... Philipp would like to write a reply on this, so I'll postpone my thoughts
> and see if we agree.  :)  But seen from a totally pragmatic perspective I
> can say, we have Jabber clients joining "MUCs" on our psyced servers. Only
> that the MUCs are in reality multicast contexts over PSYC. So without XMPP
> on the S2S part it already works fine.

But you probably forget one serious fact. The whole PSYC network belongs
to your company, isn't it? But these jabber servers around world belong
to just everyone. That means, you have no clue that there is such a
server, you have no clue how reliable such server is and if you can
trust it at all.

Some owner of company won't like the idea of his server helping other
servers in their communication, and will not like idea of his
communication being sent over any other server than absolutely
necessary. This means, his own and remote server.

And, of course, you could set-up few MUCs to be inter-connected. But you
would have to teach users to connect to their nearest one, instead of
addressing the central one. I guess these clients of yours connect to
multiple computers.

> | And, IP has a big limitation - the IP header has specified size. The IP
> | multicast is not a nice hack, in my opinion.
> 
> I wouldn't mind the hack if the channel allocation had a chance to scale.
> Around 1996 I discussed a lot with the MBONE people on how we could make
> it, that IP Multicast scales well enough so that every little chat channel
> can travel over it. PIM/SM was supposed to address that, but even that
> requires a worldwide router broadcast to allocate a channel, which is
> completely inacceptable as a large scale procedure. Not sure if this is
> still the state of things, I haven't followed up on it in a while.
> 
> But I am pretty sure you cannot allocate a Multicast IP for every person
> to send her presence, which is just a clue of what would be necessary.
> 
> Multicast is admittedly one of the hairiest and trickiest issues in
> network technology to get right, even after over fifteen years of serious
> research.
> 
That's why everyone here tries as much as possible to actually _avoid_
the true multicast. I personally would rather use bruteforce for it,
just not to complicate things. But I see it is not possible here, right?

I wish you a nice day

-- 
One semi-random fortune: 

Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary.  No such faith comforts the software
engineer.
                -- Fred Brooks

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060607/6f7f9328/attachment.sig>


More information about the Standards mailing list