junctions - an intermediate multicasting strategy in PSYCCarlo von Loesch
: MASTER » LOCAL USER : » REMOTE USER : » SLAVE : » JUNCTION » JUNCTION : » JUNCTION » SLAVE » LOCAL USERThis means, a master can host users from its own server, users from remote servers (who chose to /enter the UNI directly), slave links with or without users on them, junctions with or without users or subslaves.
How stuff goes down the drain[INFO WIE'S NACH UNTEN GEHT]
How to submit somethingIn the current situation the master is not aware of all leaves and users in the multicast tree (although we can extend it to keep data structures of all join/leave messages traveling through it).
For 0.99, junction networks are open to messages from outside the channel, thus submissions can travel from the slave or the user directly to the master. This simplification makes us ready for a prototypical release, so we'll take that for now.
Will it stay this way?Germans like to joke there's nothing more definite like a temporary solution, but we really have unique message ids just a coding day away and therefore are soon in the position of going for all sorts of crazy multicast strategies without using trees.
A little more work will take us to the distributed conference control, that was originally planned for PSYC.
Are junctions bad?In fact, no. The mere fact that each "channel" can create its own spanning tree is a huge advantage compared to IRC where every channel has to use the same spanning tree the network is using.
Imagine for example three servers at different ends of Switzerland.
They may want to link most of their rooms to their closest
international partners, one with France, another with Italy and
the third with Germany. Nowadays on IRC even private conversation
between users of such swiss servers would probably travel through
America. In PSYC instead, not only private communication would be
direct, also common swiss channels would create their own tree
which is centric to Switzerland.