[Standards-JIG] proto-JEP: Address lists

Carlo v. Loesch CvL at mail.symlynX.com
Wed Jun 7 20:37:56 UTC 2006


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.

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

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




More information about the Standards mailing list