[jdev] SamePlace 0.2.9+0.3.0prealpha

[Massimiliano Mirra]

> > > This way you would get redundancy, but I'm not sure how practical it
> > > is.  The biggest problem with any centralised architecture is that
> > > it's centralised.  This almost needs a distributed p2p
> > > rendezvous-style MUC server implementation.
> >
> > It's already setup to work in a distributed fashion.  The lookup
> > returns "places.sameplace.cc" just because that's the only server
> > hosting rooms for now.
>
> Untrue, lluna was there first, Heiner says "Currently we are hosting most
> chat channels for LLuna", so that means I join those pages using
> lluna, and SameTime it's two difference places.

Hm, I'll try to phrase that better: the specific lookup service at
"query.sameplace.cc" returns "places.sameplace.cc" because that's the
only server hosting rooms that "query.sameplace.cc" knows about, not
because the system is supposed to work with a single server.
Hopefully that's clearer now. :-)

> Idealy you'd want to
> see uses of _ALL_ virtual presence clients currently viewing the same
> page.
>
> We can't do that if the 'defaults' are different for all the client.
> (I'm talking about pages that don't have any vpi files doing
> overrides).
>
> So I guess one of the options is to load balance the mucs between the
> servers.  Say take the room name's hash: if the first charecter is <
> '8' then use lluna server, if >='8' then use sametime server.  This
> doesn't distribute well, which is why I made the p2p suggestion.

That is how the lookup would work.  It would get the room name, then
return the address of the server hosting the requested room, based on
some criteria such as partitioning of the MD5 value space, as in your
example, or actual load of each host, and/or some random salt to avoid
a room being "owned" by a particular server.  The lookup itself can be
distributed by simple round robin DNS.

Massimiliano