[Standards-JIG] proto-JEP: Smart Presence Distribution
dave at cridland.net
Thu Jun 1 08:12:31 UTC 2006
On Thu Jun 01 07:13:16 2006, Carlo v. Loesch wrote:
> Just please stop using the technical term 'multicast'
> the wrong way. If this was multicast, then you would have to say
> SMTP has
> been multicasting ever since To: Cc: and Bcc: existed. Multicast is
> when you have a tree or mesh of hosts which distribute information,
> the MBONE or IRC.
I think it's the best term available, actually. In IP, multicast
works by creating a magical address which from that point on is
basically handled as a mixture of fanout and broadcast. "Multicast"
in XMPP is pretty much the same thing.
Besides which, I'm afraid it's simply the accepted term in XMPP,
whether it's "right" or not. Inventing new terms is not a good idea,
it just confuses people.
> They all speak of temporary losses, not servers being unavailable
> longer times. I can imagine these were either affected by the
> racing condition
> on closing idle streams, or they are all on GPRS or behind evil TCP
> firewalls. But luckily federated servers don't have those problems.
Actually, it wouldn't surprise me if many servers were behind "TCP
killer firewalls". Any firewall that does connection tracking, or
stateful inspection, might kill TCP connections when it loses the
state due to a timeout or running out of slots in a table. It doesn't
have to be NAT, although I'd be willing to bet that a large number of
"federated servers" are behind NATs, too, given the enterprise usage
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards