InterMUD

InterMUD or interMU* communications is the commonly accepted terminology for different methods of allowing MUDs to communicate with each other. Some of the more common of these methods are custom protocols over the internet, IPC messages, and bots. The custom protocol method, which is by far the most popular method, has even led to the emergence of the interMUD communication network. These networks are capable of allowing numerous MUDs to communicate with each other. As a result of this ability to have so many MUDs on a particular network, it is not uncommon to have MUDs connected to two or three of these networks in order to have a wide variety of other MUDs to communicate with. Below is an overview of the more well-known custom protocols.

The first InterMUD network was created using the TMI Mudlib in 1992, when the MudOS driver incorporated network socket support.[1]

Intermud-3

Intermud-3, more commonly referred to as I3, uses TCP connections in order to connect each MUD to a central server, where most messages are routed through the server to other MUDs. In addition, I3 permits OOB (out-of-band) connections between MUDs, which temporarily results in direct communication between two participating MUDs. One of the primary benefits of I3 is that it allows MUDs to connect to I3 networks without server admin intervention. In recent years, I3 has been extended to support multiple routers on a single network for load balancing and redundancy.

Since its initial incarnation in the mid 90s, the I3 protocol has gone through 3 revisions, adding various new features and suggestions for a future inter router network. As of early 2007, a practical inter router network implementation exists, and as of late 2008, an inter router network specification is available.[2]

Currently, there are three major I3 networks: gjs, which was run by Greg Stein (Deathblade); yatmim, which is run by the maintainer of the Dead Souls Mudlib; and adsr, which is run by the team at Anarres. Unfortunately the gjs network, which was the first public I3 network, is no longer very stable. As of March 2007, the gjs router has been down for over seven months. This has resulted in yatmim becoming a very popular network. Disagreement over network policy led to the creation of adsr as an alternative to yatmim.

There are also a few isolated servers that are used primarily for testing purposes.

Some of the services supported by I3

Note: Not all services are supported by all MUDs. A lot of these are listed as optional in the protocol.

Software

To connect a MUD to the main I3 network or to one of the private I3 networks, an I3 client implementation will be needed. To facilitate this process, many open-source MUD implementations are distributed with I3 clients included. It is also possible to use the I3 specifications in order to create a custom implementation.

For those interested in creating his or her own private I3 network, there is currently only one open source server implementation that is publicly available. This implementation is Tim's implementation. It is also possible to use the I3 specifications and the inter router network specifications in order to create a custom implementation.

The latest release of the Dead Souls Mudlib contains a functional implementation of an I3 server, based on Tim's implementation, enhanced with administration commands and inter-router networking extensions.

IMC2

IMC2 is short for InterMud Communications Protocol Version 2. Similar to I3, IMC2 connects MUDs using TCP connections and allows MUDs to connect without server administrator permission. The IMC2 protocol supports multiple routers on a single network in a way similar to I3 (and did so a lot earlier). However, one of the ways that IMC2 differs significantly from I3 is that it does not use so called mudmode connections, making it much easier to implement IMC2 on muds not written in LPC.

Currently, there is only one active IMC2 network in use, MudBytes InterMud Communication Network.

Some of the services supported by IMC2

Note: Not all services are supported by all MUDs.

Software

In order to connect a MUD to an IMC2 network, an IMC2 client implementation will be needed. There are several IMC2 client implementations that are publicly available, including ones for LPMuds and Java MUDs. The most commonly used one for DikuMUD derivatives is the IMC2 Freedom implementation. In addition, it is also possible to use the IMC2 specifications in order to create a custom implementation.

For those interested in creating their own private IMC2 network, the most commonly used server implementation is the IMC2 Freedom implementation.

AberChat

AberChat is used primarily by the type of MUD known as AberMUD. It uses TCP connections to connect each MUD to a central server. Some of the more distinctive characteristics of AberChat is that it does not rely on client MUDs to keep track of the other MUDs on a network, and it does not update a local list when other MUDs on a network become available or unavailable. Instead, in order to see what MUDs are out there, MUD users can send a request for a list of MUDs on the network to the server, which replies with a complete list.

There is both a public and a private AberChat network. Both require the server administrator to manually add a new MUD to the network.

Services supported by AberChat

Note: Mail is not supported in older client implementations.

Software

In order to connect a MUD to an AberChat network, an AberChat client implementation will be needed. There are several AberChat client implementations that are publicly available on the SMiLE download page, as well as a SMAUG client at MudBytes. In addition, it is also possible to use the AberChat specifications in order to create a custom implementation.

For those interested in creating his or her own private AberChat network, there is a publicly available server implementation located at MudBytes.

MushLink

MushLink is primarily used on MUSHes. It uses a TCP connection in order to connect a MUD to the central server. In contrast to the other interMUD networks so far listed, MushLink's server actually connects to the MUD instead of having the MUD connect to the server. This connection consists of a bot that logs in as a special user. This user uses special commands in order to both display and receive messages from the MUD.

Services supported by MushLink

Software

MushLink requires no special code to be used on a MUSH. However, a MUSH needs to support the standard MUSH commands in order for the MushLink bot to work. For MUSHs that do not support the standard MUSH commands, it is possible to emulate them.

The MushLink bot itself can be downloaded from PennMUSH web site.

MudNet

MudNet is derived from MushLink. It mainly differs from MudNet in that it supports some additional commands, supports more MU* types, and supports interMU* communications on certain MUSH types' own channel systems. The MudNet credits page provides more detail on the differences.

MudNet is now defunct - it was shut down on March 14, 2010.[3]

Merentha InterMud Services (MIS)

MIS was written specifically for the Merentha Mudlib, a specific MUD implementation. It uses UDP, instead of TCP, and sends directly to all MUDs that the sending MUD knows. There are no servers involved because it is entirely client-to-client communication.

Services supported by MIS

Some Other Custom InterMUD Communication Protocols

References

  1. ↑ Mulligan, Jessica; Patrovsky, Bridgette (2003). Developing Online Games: An Insider's Guide. New Riders. pp. 455–456. ISBN 1-59273-000-0. 1992 [...] First instances of interMUD networks created using LP. "LPC sockets are added to the MudOS driver. This allows TMI to create a very rough TCP interMUD network. This protocol is later replaced first by the CDlib UDP protocols, and later by InterMUD 3." —George Reese
  2. ↑ "http://wotf.org/i3/irn/v1/".
  3. ↑ "The MudNet Team: MudNet News". Retrieved 13 February 2012.

External links