This post will be of interest mostly to weirdoes who are curious about intermud protocol
stuff. If you do not count among their number, you can very safely skip this post.
The current release of DS2 alpha, 2.5a7, contains fixes and upgrades to the Inter Router Networking
system. It has been tested with 4 IRN nodes and works very well.
However, it is a departure from the way the original I3 designers planned to do things. A read
of the specs at
http://www.intermud.org/i3/ strongly suggests that their vision for inter router communication
was something like that of the internet, able to route around damage and ostensibly completely open.
This is not an approach I've taken with IRN for the following reasons:
1) I am not an experienced enough network designer to code a parallel internet.
2) There is no reason to do that.
3) A completely open design runs counter to the ability to have "conditions of use", a key part of I3.
Instead, the principle behind the IRN is of a "trusted network" of peers
that authenticate with each other, and share data only when that data
is relevant to a channel, mudlist, or when the local router does not
contain the mud that is targeted by a local request.
Rather than a fault-tolerant web of redundant nodes, the IRN is designed
as discrete islands that broadcast to other islands when the data is
channel-based, mudlist-based, or if the mud that is being queried is not local.
For example: the router named *mars has muds named Deimos and Phobos connected
to it. Daniel@Deimos sends a tell to Phanny@Phobos. Because this message is
within the local scope, *mars does not send this message out on the IRN. It
simply sends the message to to Phobos without involving IRN at all.
On the other hand, if *saturn has a mud named Titan connected to it, and
Trevor@Titan wants to tell to Phanny@Phobos, then the IRN is involved. When
*saturn sees that Phobos is not a mud connected to it, it will broadcast
the message to each router on the IRN. Since *mars is on the IRN, it will
determine that Phobos is one of its muds, and deliver the message.
The problem with this broadcast is that if the IRN is completely open,
and anyone can join, then this tell is effectively a channel message, since
anybody is permitted to receive it.
One way to prevent this is to establish complex authentication schemes that
involve two-part keys. This is a valid scheme. It is well beyond anything I
possess the skill or interest in implementing.
Instead, IRN is simply not an open framework. Rather than have anyone
become a node on the intermud network, nodes have to be known and have
known passwords. This means that if *xena wants in on the IRN, her name
and password better be known to the other nine nodes on the IRN.
In practice, this is set up in irn.h like this:
string my_name = "*mars";
string my_password = "fox";
string *ok_ips = ({});
int irn_enabled = 1;
int irn_maxtry = 32;
static int convert_channel = 1;
static int convert_channel2 = 0;
static mapping routers = ([
"*mercury" : ([ "ip" : "10.0.0.1", "port" : 2001, "password" : "the" ]),
"*venus" : ([ "ip" : "10.0.0.2", "port" : 2001, "password" : "quick" ]),
"*earth" : ([ "ip" : "10.0.0.3", "port" : 2001, "password" : "brown" ]),
//"*mars" : ([ "ip" : "10.0.0.4", "port" : 2001, "password" : "fox" ]),
"*jupiter" : ([ "ip" : "10.0.0.5", "port" : 2001, "password" : "jumped" ]),
"*saturn" : ([ "ip" : "10.0.0.6", "port" : 2001, "password" : "over" ]),
]);
If a mud attempts to join the IRN but lacks the proper password to the
router it tries to authenticate with, it will be rejected. If it
has the right password but is coming from an IP that is not known
to be associated with it, it is rejected. Every router
has to be trusted enough to have the password for every other router,
and as a safeguard against password capture, even if a mud
uses the right password to authenticate with another node, if the
IP of that mud is not known to the target node as belonging to
the originating router, the target node refuses to authenticate.
Note that once a member of the IRN, a malicious node admin can wreak quite
a lot of havoc. This is why the concept of a "trusted" network is
emphasized. Peers must be, in fact, known and trusted entities.
Following this model, mudlist updates are sent out to each node
only from the the node that has the relevant mud connected to it.
Therefore, if Phobos disconnects from *mars, only *mars broadcasts
this information. *jupiter, seeing that it was not Phobos's host,
does not bother trying to update *saturn with Phobos's status.
The presumption is that though nodes on an IRN will be cooperative
and such, there is no need to broadcast every single bit of data
from each node to each other node, if actual internet routing
protocols are not to be modeled.
IRN allows communication between muds not connected to the same
router, while preserving each router's privacy and independence
of a "global policy" as much as possible, within the explicit
Intermud-3 protocol.
-Crat
