Intermud-3: a Proposal for The Future

Initial protocol design by: Greg Stein ( John Viega ( Tim Hollebeek ( Please forward discussion to the Intermud mailing list at You may subscribe by mailing Place "subscribe intermud" in the body.

This document details a proposal for a future generation of Intermud protocols. It is designed to use the high level communication facilities provided by the MudOS LP driver. Other drivers may be capable of handling the communication protocol, but this proposal does not focus on them. See Other Drivers for a possible scheme to include them into the Intermud as defined by this proposal. This document has the following sections: Contributors and Implementors : lists the contributors to this specification and people who have created I3 implementations (for public or private release) Logical Network Layout : describes how the muds connect to each other Packet Format : describes the basic format of all packets Services : describes the services available Support Packets : describes additional packet types for maintainance purposes OOB Protocols : describes the protocols used for OOB communications Router Design : describes the design of the routers Other Drivers/Mudlibs : describes an approach that could be used to include non-MudOS drivers Error Summary : quick summary of the error codes used Packet Types Summary : quick summary of the packets that are used Compressed Mode : describes a scheme for compressing the transmitted data Change Log : lists recent changes to the specification

Many people have contributed to this specification. This is an attempt to list those people who have helped in some way or another. Also, there are a number of implementations out there now. This list should help with locating resources for picking up an implementation for for finding people who have an implementation similar to your needs. Contributors: As mentioned at the head of this page, the core designers of this protocol were: Deathblade (Greg Stein, Rust (John Viega, Beek (Tim Hollebeek, Descartes (George Reese,

1 of 27

6/28/2013 10:06 AM

Intermud-3: a Proposal for The Future

Descartes contributed in a number of areas, particularly as one of the pioneer implementors after the initial development by the Lima Mudlib team. Deathknight (Jesse McClusky, Deathknight was the original contributor of the central router-based, backbone design of the current I3 system. There are, of course, many other contributors who offered input both at the conference in February '95 and on the intermud mailing list. Their omission is not by design, but because informartion wasn't available at the time of this writing (they didn't provide info). Implementations: The Lima Mudlib contains an implementation of the Intermud-3 system (written by Deathblade). This was the first implementation to exist and is one of the few that is readily and publically available for use by other systems. It was implemented for the MudOS v22 driver. It is publically available at: The Nightmare Object Library also contains an implementation of the Intermud-3 system (written by Descartes). This implementation is also one of the oldest around, originating soon after the Lima version and first appearing in the release of Nightmare IV. The Intermud-3 system for Nightmare (and Foundation) has also been pulled out into its own package, available at: Terry (Terry Penn, has created two implementations of the Intermud-3 system. One is for Shadow's Edge running LPMUD 3.2.1@122 Another for MudOS v22a18 Both of these are running on custom mudlibs and are not generally available. Logic (Edward Marshall, has written an implementation for LPmud 3.2.1 for the private mudlib EOTSlib. He has potential plans for a public release of the I3 package. Skylight (Patrick Li, Hanzou (James Donald Jr., They have written a version for LPmud 3.2.1@98 (or later). The package is primarily aimed for 2.4.5 mudlibs and is available at: Deathblade and Cowl (Hal Schechner, designed and implementated the Intermud-3 router currently in use at As always, there are many others out there, but they have not submitted information yet for inclusion here.

The logical network of muds is organized into a set of fully connected routers each acting as a hub for an arbitrary set of muds. A mud has a "preferred" router, but will be told and will record information about all routers in existence (for
2 of 27

6/28/2013 10:06 AM

The data carried over these connections will be limited to "fast response" messages. Each router will hold a list of all muds within the intermud and which router the mud is connected to. This may not be absolutely necessary. news. The routers open and maintain TCP sessions (using MudOS's "MUD" mode) to each of the other routers (fully connected network). each mud may maintain a UDP port for some specific OOB transmissions. This is similar to an IP packet's TTL . etc). At the moment. but with different casing. but provides a mechanism to handle the case where the routers mis-route a packet into an endless loop. Idea Exchange. ttl is the packet's Time To Live (TTL). originator mudname. target mudname. See Packet Types for a summary of the packet types used in this protocol. Some services will be carried off of this network and are called "out of band" (OOB) transmissions. the services that use the OOB transmissions are mail. The case is significant. Eventually. At the moment. 3 of 27 6/28/2013 10:06 AM . An active TCP session (in MUD mode) is maintained between a mud and its router. although the routers may (?) disallow two muds with the same name. there are no UDP-based OOB services. Connections will be opened as needed and closed when the transmission completes. }). with spaces..stack. Each mud will listen at a TCP port for incoming connections for processing OOB transmissions. though. The network of TCP sessions between the routers and muds will be used for "in band" transmissions. type describes the type of the packet. there are a few cases where a router must be referenced. and file transfers. routers will be distinguished from muds with a leading asterisk (such as *nightmare). A mud's preferred router may be changed programatically to handle load balancing among routers. ttl.. Muds may not define a name with a leading asterisk if they wish to be a part of the Intermud. originator username. These names will be used in the mudlist and in all packet specifies the number of hops left to a packet. The mud is responsibile for opening (see the startup-req-2 packet). maintaining. Transmissions are LPC arrays with a predefined set of six initial elements: ({ type. Examples: Quendor. muds must use a canonical naming system. MUD Naming For proper identification within the Intermud network. A dropped connection will wait 5 minutes before delivering "down" state notification (this 5 minutes is provided for the mud to reconnect). reconnecting.html failover in case the preferred is down). target username. Lastly.Intermud-3: a Proposal for The Future http://mud. Routers will have names assigned to them. so this port is typically not opened. A graceful exit will cause the router to propogate information about the "down" state of the mud to the other routers and muds on the intermud. . A mud is removed after 7 days of being in the down state. The canonical name is defined to be the mud's actual name (properly capitalized. it will time out and be removed from the and shutting down this session.

this mud will be notified. The username may be 0 if the packet is targeted for the mud itself rather than a specific user. this is equivalent to the username with altered capitalization.Intermud-3: a Proposal for The Future http://mud.the name which should be displayed to other users. target username is used to route the packet to a particular user on a remote mud. then the username will be 0. target_username. The username should be in lower-case. mail delivery or shutdown notification).stack. This is a user's "visible" name . 5. There are eleven services covered by this proposal: tell : send a message to a user on a remote mud emoteto : send an emote to a user on a remote mud who : get a list of users on a remote mud finger : get information about a particular user on a remote mud locate : locate a player on a remote mud(s) channel : send a string/emote/soul between muds news : propogate news posts between muds mail : propogate mail items between muds file : transfer a file between muds auth : perform mud or user authentication ucache : cache information about remote users Service: tell The originator will deliver the following packet to the target mud over the in-band network (to its router): ({ (string) (int) (string) (string) (string) (string) (string) (string) }) "tell". Zero is used to indicate broadcast packets. If the mud itself sent the packet (e. the message will be delivered to target_username. if possible. Many packets will specify a visname. originator_username. If the packet cannot be delivered for some reason. The target mud will attempt to find the user with whatever appropriate means. target mudname is used to route the packet to the appropriate destination mud. The orig_visname is told to the 4 of 27 6/28/2013 10:06 AM . target_mudname. message At the target mud. originator username is used to indicate the user that triggered the delivery of the packet.html originator mudname is used to indicate the mud where the packet originated. but may actually be quite arbitrary with respect to the username.g. This should always be in lower-case. originator_mudname. Typically.

Intermud-3: a Proposal for The Future http://mud.stack. it will return an error packet. The target_username should be lower-cased by the originating mud. originator_mudname). originator_username. originator_mudname). originator_username. who_data 5 of 27 6/28/2013 10:06 AM . 5. "$N smiles at you. This name is typically formatted using: sprintf("%s@%s". target_mudname. The target mud returns: ({ (string) (int) (string) (string) (string) (string) (mixed *) "who-reply". the message will be delivered to target_username with the appropriate formatting." which would be transformed into something target_mudname. 5. it is usually combined with the originator_mudname as: sprintf("%s@%s". target_username. "Joe@PutzMud smiles at you. originator_mudname. 0. orig_visname.html target_username to indicate who sent the message. The message will contain $N tokens for substituting the originator's name. Service: emoteto The originator will deliver the following packet to the target mud over the in-band network (to its router): ({ (string) (int) (string) (string) (string) (string) (string) (string) }) "emoteto". The target_username should be lower-cased by the originating mud. If the router fails to deliver the packet for some reason. orig_visname." If the router or target mud fails to deliver the packet for some reason. orig_visname. originator_mudname. 0 The router will route the packet to another router or to the target mud. originator_mudname. 5. Service: who The originator will deliver the following packet over the in-band network (to its router): ({ (string) (int) (string) (string) (string) (string) }) "who-req". target_username. message At the target mud. target_mudname. A simple example would be a message such as. it will return an error packet.

idle_time. level. or any other relevant info A mud may return 0 for any item if they wish to keep the information private. target_mudname.stack. The target mud will return: ({ (string) (int) (string) (string) (string) (string) (string) (string) (string) (string) (string) (int) (string) (string) (string) }) "finger-reply". ip_name. This service uses the in-band network. it is suggested that information about players (as opposed to wizards) be kept confidential. 0. idle_time should be measured in seconds and xtra_info should be a string. In particular. originator_mudname. originator_username. Service: finger Finger operates similarly to who but returns information about a specific user rather than all users logged into the mud. If the router fails to deliver the packet for some reason. originator_mudname. a . the packet has the following format: ({ (string) (int) (string) (string) (string) (string) (string) }) "finger-req".Intermud-3: a Proposal for The Future visname. The returned visname should contain the user's visual name. target_mudname. it will return an error packet. real_name. idle_time. The packet is only querying information about the user.plan file. target_username. extra // eg. 0. e_mail.html }) where who_data is an array containing an array of the following format for each user on the mud: ({ (string) (int) (string) }) user_visname. loginout_time. loginout_time specifies the (local) time the user 6 of 27 6/28/2013 10:06 AM . 5. we could use the target_username field to hold the name of the person to finger. but we do not wish to imply that the packet is destined for that user. title. xtra_info Each user_visname should specify the user's visual name. 5. username Note: technically.

5. 5. instead leaving that to the receiving mud. The values for this string are arbitrary. 7 of 27 6/28/2013 10:06 AM . The located mud should not attempt to apply special formatting or other characters. then the following reply is returned: ({ (string) (int) (string) (string) (string) (string) (string) (string) (int) (string) }) "locate-reply". originator_mudname. located_mudname. The value should be expressed as a string.html logged in (if they are currently on) or the time the user logged out. username If the requested user is logged into the receiving mud. hidden". If this value is -1. idle_time.stack. Service: locate This service locates a particular user on the Intermud system. It should be 0 to indicate no information. status specifies any special status of the user. which then delivers it to all muds (target_mudname == 0): ({ (string) (int) (string) (string) (string) (string) (string) }) "locate-req". then it should be terminated with a carriage return. target_mudname. If extra is given. The idle_time is expressed as an integer number of seconds of idle time. originator_mudname. then the user is not logged onto the mud at the This will typically be zero to indicate that the user has no special status. status. idle_time will have the idle time (in seconds) of the located user. target_username. located_visname.Intermud-3: a Proposal for The Future http://mud. The predefined way to specify multiple attributes is with a comma-space-separated list such as: "editing. The following packet is delivered over the in-band network (to the mud's router). 0. located_visname should contain the correct visual name of the user. but certain statuses have predefined values that can be used: "link-dead" "editing" "inactive" "invisible" "hidden" These predefined values are intended to cover those statuses that might modify a user's reception of Intermud transmissions. 0. originator_username. they are not intended to be all-inclusive (and the string is arbitrary in any case). 0.

Channel messages come in three flavors: standard messages. emotes. target_mudname. ({ (string) (int) (string) (string) (string) (string) (int) (mapping) }) "chanlist-reply". They are: ({ (string) (int) (string) (string) (string) (string) (string) (string) (string) "channel-m". 0.Intermud-3: a Proposal for The Future http://mud. channel-e. 0. Selectively banned. filtered channels are not allowed.html Other examples for the status string might be "afk for dinner" or "taking a test". originator_mudname. and one list for selective admission. channel_list // the router channel_list is mapping with channel names as keys. For each channel. although this may subject that mud to an increased load for processing the channel contents and the channel will become unavailable when the host mud is down. 0. If the value is 0. it will then return to the router network for distribution. and a list of muds that are admitted/banned. the owning mud of the channel. The array contains the host mud.stack. The router will respond to channel list changes with the chanlist-reply packet. The owner of a channel may also choose to filter the channel. The router will potentially respond with a chanlist-reply message to update the mud's channel list. channel_name. list for each type of channel (selective admission vs banning) where the channel is unfiltered. originator_mudname. These use packets channel-m. It will then pass the message to the appropriate set of muds. respectively. 5. originator_username. and channel-t. When a mud sends a startup-req-2 packet. If the channel is filtered. and targetted emotes. it includes its chanlist-id in the packet. All channels are owned by a particular mud and are adminstrated by that mud only. Service: channel There are two types of channels in the Intermud system: selective admission and selective banning. the router will store which type it is (what list it is on). 5. and the type of the channel: 0 1 2 selectively banned selectively admitted filtered (selectively admitted) All channel messages are delivered to the router. filtered channels. It is assumed that a channel packet for a filtered channel that comes from the channel host has been filtered. The routers maintain three channel lists . then the packet will be delivered to the host mud for filtering. then the channel has been deleted. and an array of two elements as the values. 0. message 8 of 27 6/28/2013 10:06 AM .

originator_mudname.Intermud-3: a Proposal for The Future http://mud. originator_mudname. it should deliver the message locally to all listeners. A suggested format is: [gwiz] With a flying leap. The messages will include $N and $O for the name of the originator and the object/target of their emote. but the message has a token in it to represent where the originator's name should" ### need more info here ### When a mud receives a channel-t packet. The actual message delivered should be a composition of the channel_name and one of message_others or message_target. channel_name. These were composed with: sprintf("[%s] %s". targetted_mudname. channel_name. then the message_target should be used. originator_mudname. originator_username. message_others.html }) ({ (string) (int) (string) (string) (string) (string) (string) (string) (string) }) ({ (string) (int) (string) (string) (string) (string) (string) (string) (string) (string) (string) (string) (string) }) "channel-t". and message. channel_name. targetted_username. [gwiz] Jane@BlandMud waves to you. message_target. 0. visname. visname. channel_name. 5. 0. one_of_the_messages). message When a mud receives a channel-m packet. An example is "$N smiles. 9 of 27 6/28/2013 10:06 AM .stack. The message should not be preformatted with this information before delivery so that individual muds can define the display semantics. 0. channel_name. 0. it should deliver it locally to all listeners. The actual message delivered to users should be a composition of the originator_mudname. A suggested format is: [gwiz] John@Doe Mud: help me! help me! I am a cluebie newless! This was composed with: sprintf("[%s] %s@%s: %s". John@Doe Mud falls into the pit. 5.if the listener matches the targetted mud/user. message). originator_visname. visname. channel-e packets are similar to channel-m packets. [gwiz] Jane@BlandMud waves to Goober@PutzMud. The appropriate message is selected based on the listener . This token is $N. originator_username. target_visname "channel-e".

target_mudname. 5. A channel may be added with the following packet: ({ (string) (int) (string) (string) (string) (string) (string) (int) }) "channel-add". channel_type // the router The for channel_type field accepts the same values that the name server returns for channels. The target_username should be in lower-case if provided. the channels host/owner mud may use the following packet: ({ (string) (int) (string) (string) (string) (string) (string) (string *) (string *) }) "channel-admin". 5. To filter a channel.that will be applied on the receiving mud if necessary. target_mudname. originator_username. channel_name. // the router // the owner/host mud 10 of 27 6/28/2013 10:06 AM . target_mudname. 0. 0. add_to_list. originator_mudname. target_mudname. channel_name.Intermud-3: a Proposal for The Future http://mud. 0. A channel may be removed by the mud that created it by sending the following packet: ({ (string) (int) (string) (string) (string) (string) (string) }) "channel-remove". remove_from_list // the router The muds specified in add_to_list are added to the allowed/banned list stored within the router network. Sending this packet again with a new value for channel_type will change the information. The muds specified in remove_from_list are removed from that 5. 0. originator_username.stack. originator_mudname. originator_username. originator_mudname. originator_mudname. 0. the following packets will be used : ({ (string) (int) (string) (string) (string) (string) "chan-filter-req". channel_name // the router To administer a channel.html ### need a bit more on channel-t ### All messages should not be terminated with a newline . 5.

on_or_off // the router 11 of 27 6/28/2013 10:06 AM . which should be done whenever no one on the mud is listening to the channel.stack. channel_name The reply for the who request takes the following format: ({ (string) (int) (string) (string) (string) (string) (string) (string *) }) "chan-who-reply". 5. 5. filtered_packet.Intermud-3: a Proposal for The Future http://mud. 0. 0. originator_mudname. The filtered packet is returned to the router in the following packet : ({ (string) (int) (string) (string) (string) (string) (string) (mixed *) }) "chan-filter-reply". channel_name. This packet is also used to tune out a channel. 5. A mud may decide whether or not it is listening to any given channel by sending a channel-listen packet. originator_mudname. target_mudname. originator_mudname. channel-e or channel-t packet. 5. // The channel host/owner mudname // the router A list of who is listening to a channel on a remote mud may be requested with the following packet: ({ (string) (int) (string) (string) (string) (string) (string) }) "chan-who-req". target_username. (string) (mixed *) }) channel_name. user_list The user_list should be an array of strings. 0. channel_name. target_mudname. 0. The format of this packet is: ({ (string) (int) (string) (string) (string) (string) (string) (int) }) "channel-listen". Where packet_to_filter is a channel-m. target_mudname. target_mudname. representing the users' "visual" names. originator_username. 0. channel_name. 0. originator_mudname.

Instead. Lastly. it is necessary to get information on the target.stack. username. Service: news ### work to do here. and reflexive words. 0. originator_mudname.. target_mudname. 0. but most human languages only have three forms at most. There are two pieces of information required: the visname and the gender of the target. This operation is performed with the following packets: ({ (string) (int) (string) (string) (string) (string) (string) }) "chan-user-req". username Note that the username is separate since the packet is not targetted to the user. gender The gender takes one of the following values: 0 1 2 male female neuter Note that a mud may have more variants on gender. These are used to select the appropriate pronouns. for targetted emotes. The reply for the user info request takes the following format: ({ (string) (int) (string) (string) (string) (string) (string) (string) (int) }) "chan-user-reply". originator_mudname. 12 of 27 6/28/2013 10:06 AM . 0. 0. This connection should not disconnect from the server until it is done dealing with it for the forseeable future. target_mudname. 5. ({ (string) (int) (string) (string) "news-read-req". 1 The mud wishes to receive this 5. also employing the auth service ### This packet is used to transmit a request for a post to a remote mud's news server (via the OOB network).Intermud-3: a Proposal for The Future http://mud.. possessives. this is an OOB service. originator_mudname. visname. it should exchange messages in lockstep with the server. originator_username. 5.html The on_or_off will contain one of the following values: 0 The mud does not wish to receive this channel.

0. poster. contents To post a message. subject. 13 of 27 6/28/2013 10:06 AM . The server response should be an integer representing the id of the post.stack. bcc_list. mud_login_port. id. to_list. orig_user. cc_list. id.Intermud-3: a Proposal for The Future http://mud. This array should contain the following data: ({ (string) group_name. thread_id. (int) last_post_id }) Service: mail This packet is used to deliver a mail message to a remote mud. originator_mudname. send the following packet: ({ (string) (string) (int) (string) (string) (string) (string) (string) }) "news-post-req". or an error packet. poster.html (string) (string) (string) (int) }) 0..e. because it is not transmitted over the in band network. (int) first_post_id. send the following packet: ({ (string) "news-grplist-req" }) The response from the server should be an array containing an array for each available group. newsgroup_name. It has the following form: ({ (string) (int) (string) (mapping) (mapping) (string *) "mail". To request a list of newsgroups. subject. mewsgroup. over a direct TCP connection to the target mud's out-of-band TCP port). The server response for this request takes the following form: ({ (int) (string) (string) (string) (string) }) posting_time. It will be delivered over the OOB network (i. contents Notice that this packed does not follow the standard packet form.

}) Where dir_list is an array containing an array of the following format for each file in the reply list: ({ (string) dir is considered to be relative to a world read/write directory. Where to_list and cc_list are mappings of the following format : ([ MUD-A : ({ user-1. Errors must be sent via the OOB network Service: file ### work to do here. dir. The response from the remote mud should be: ({ (string) "file-list-reply". MUD-B : ({ user-1. subject. this is an OOB service. Mail is acknoleged by the use of a "mail-ack" packet. }). (string) target_username. }). and employs the auth service. a session token must be returned from the remote mud using the login protocols. send the following packet: ({ (string) (string) (string) (string) }) "file-list-req". It will use the out-of-band TCP port and has the following form: To list the files on a remote mud. user-2. Where ack_list is a mapping whose keys are the id's that have been acknowleged. originator_username. and the values are arrays of the failures. user-2. contents.stack. (mixed *) dir_list.. ({ (string) (mapping) }) "mail-ack". ack_list.html (int) (string) (string) }) send_time.Intermud-3: a Proposal for The Future http://mud. Where dir is the directory to be listed. also employing the auth service ### ### this service still in development ### This service is used to transfer files between muds. 14 of 27 6/28/2013 10:06 AM . Any leading '/' is ignored. NB: mail is an OOB service. originator_mudname. ]) and bcc_list is an array of the users at the target mud only. Before files may be transferred.

originator_mudname. originator_mudname. remote_fname. -3 -2 -1 0 1 : : : : : Request Request Request Request Request Failed (write permission) Failed (read permission) Failed (fpath error) Failed (unknown error) successful The file should only be transfered from a world writeable directory on one mud to a world writable directory on another. Puts are acknoleged by the following packet : ({ (string) "file-put-ack". 15 of 27 6/28/2013 10:06 AM . send the following packet: ({ (string) (int) (string) (string) (string) (string) }) "file-put". id. Where success corresponds to the following. The size of the file capable of being sent in this manner is limited by the size of the maximum string length on both the sending and receiving muds. contents. To send a file to a remote mud. remote_fname is relative to the same directory as file-list-* and any leading '/' is ignored. success. originator_username. }) To retrive a file from a remote mud. send the following packet: ({ (string) (int) (string) (string) (string) }) "file-get-req". contents. id.stack.html (int) (int) }) fsize. remote_fname. The remote mud should respond with ({ (string) (int) (int) (string) }) "file-get-reply".Intermud-3: a Proposal for The Future http://mud. ftime. An error response should be returned over the OOB network. (int) id. (int) success. originator_username.

the target mud may discard the key and reject connection attempts with that key. the originator may contact the target mud through the OOB port. Service: ucache The ucache service is used for maintaining user information caches within the Intermud network. and then returns the key (over the in-band network) to the originator with: ({ (string) (int) (string) (string) (string) (string) (int) }) "auth-mud-reply". 0 The target mud generates a unique integer key. associates that with the originating mud with the key.Intermud-3: a Proposal for The Future http://mud. using the session_key to authenticate that it actually is the purported originator. The authentication is used to verify that an incoming OOB connection request is actually from the mud that the request says it is from. Before the OOB connection is made. which are then used by muds that implement the ucache service. Only the last request and session_key need to be remembered.html Service: auth The auth service is used for performing authentication of a mud. After a successful OOB connection is made. originator_mudname. A mud may cache information that it receives from chan-user-req packet. The keys from prior requests may be discarded and connection attempts using them may be rejected. Whenever the contents of a chan-user-reply packet would change (visname or gender). then the mud should broadcast the following packet: ({ (string) "ucache-update". the target mud may discard the key (the key should be interpreted as a one-time key). that a particular originator might issue multiple auth-mud-req packets before establishing an OOB session to the target mud. 0. 5. session_key At this point.stack. target_mudname. 0. After that point. 16 of 27 6/28/2013 10:06 AM . To keep this up to date. 5. This authentication is used for OOB communications since in-band communication is always authenticated at a mud-level. 0. muds should issue ucache-update packets. the originator sends the following packet (over the in-band network) to the target mud: ({ (string) (int) (string) (string) (string) (string) }) "auth-mud-req". Session keys must remain valid for 10 minutes from receipt of the auth-mud-req and should be accounted for. originator_mudname. target_mudname. It is possible.

but should be a message that can be displayed to a user. target_username. 0.e. If the mud has never received a password from a server. A startup-req-3 packet has the following form: ({ (string) (int) (string) (string) (string) (string) "startup-req-3". If the packet is unavailable (i. target_mudname. 5. 0. The error_message does not follow any particular standards (yet?). It has the following form: ({ (string) (int) (string) (string) (string) (string) (string) (string) (mixed *) }) "error".html (int) (string) (string) (string) (string) (string) (string) (int) }) 5. username. 0. originator_mudname. then the value 0 may be used. The error_packet may contain the packet that caused the particular error to be generated. target_mudname. // the router 17 of 27 6/28/2013 10:06 AM . 0. error This packet is returned when error conditions arise. The server is responsible for creating a random password for new muds. 0. visname. error_code. startup-req-3 This packet is delivered to a mud's router when the mud first establishes the connection. originator_mudname. 0. gender The contents of this packet are similar to the chan-user-reply packet. Note that the router will filter this packet's delivery to only those muds that support the ucache service.Intermud-3: a Proposal for The Future http://mud. and validating the password of a mud before allowing a mud to connect from a site other than the one from which it normally connects. due to code structure).stack. originator_mudname. it should send 0. error_packet The error_code values are standardized and are summarized in the Error Summary section. 5.

The router network must support all protocol versions and must translate packets between muds with different protocol versions. All pieces of information are required to be sent to a router except for the port numbers and other_data. open_status is a string describing the current status of the mud. services that are only available in later protocol versions). (string) driver. MOO services is a mapping with service names as keys. extended (non-standard) services may be specified with service-specific information for their value.html (int) (int) (int) password. Error packets will be returned to a mud if that mud attempts to use a service that cannot be translated (e. In addition. (int) imud_tcp_port.g. (string) admin_email. Here is the current list of services (keys and values) that a mud may make available along with some example extended services: "tell" : 1 "emoteto" : 1 "who" : 1 "finger" : 1 "locate" : 1 18 of 27 6/28/2013 10:06 AM . // these correspond to the values in a mudlist info_mapping (int) player_port. other_data may be 0 if a mud has no "other data" (see below). (string) base_mudlib. these simply have a value of 1 in the mapping. (string) mud_type.Intermud-3: a Proposal for The Future http://mud. No other changes were made to the specification. Suggested (strongly encouraged values) are: "mudlib development" "beta testing" "open for public" "restricted access" mud_type specifies the type/family/genre of the mud driver. (int) imud_udp_port. Examples are: LP. The allowable services include those specified within this specification (in the Services section). (string) mudlib. (string) open_status. old_chanlist_id. The OOB ports may be 0 if the services that require them will not be provided by the mud. Future changes in the protocol can update this number as required. Note: version 2 of the protocol had a smaller locate-reply packet. (mapping) services (mapping) other_data }) The -3 on the packet type indicates that the mud will use Protocol Version 3 for communication (this specification). The player_port may be 0 if the mud is private/closed. Note: version 1 of the protocol was almost exactly the same as this version except that it was missing a couple fields from the startup packet and the corresponding info_mapping in the mudlist packet.stack.

The other_data field (when provided) contains a mapping with string keys. It is highly recommended that attempts be made to avoid namespace collisions. "rcp" : port-number Specifies the port number of a mud's Remote Creator server (currently a facility provided by Nightmare Lib IV). router_list.stack. These key/value pairs are used to specify information that is not related directly to the I3 network operation. "http" : port-number Specifies the port number of a mud's WWW server (httpd). Individual muds are free to define their own key/value pairs. or when the set of routers change for some reason. Note that Intermud mail is normally delivered via the OOB TCP port. ({ (string) (int) (string) (string) (string) (string) (string *) (int) }) "startup-reply". when the router wishes the mud to connect to a different router. "ftp" : port-number Specifies the port number of a mud's FTP service. Additional services and service-specific data may be added in the future as required. 0. The values are arbitrary and determined by the key. Note that Intermud news transfer is normally delivered via the OOB TCP port. startup-reply This packet will be delivered to a mud for three conditions: in response to a startup-req packet. "nntp" : port-number Specifies the port number of a mud's NNTP "channel" : 1 "news" : 1 "mail" : 1 "file" : 1 "auth" : 1 "ucache" : 1 "smtp" : port-number Specifies the port number of a mud's SMTP mail interface. At this time. target_mudname. originator_mudname. it might use a key of "lima-somekey".Intermud-3: a Proposal for The Future http://mud. if the Lima Mudlib decides to place an entry into the other_data field. password // the router 19 of 27 6/28/2013 10:06 AM . 0. there are no defined keys in this specification or via precedent. For example. 5. "amcp" : version-string Indicates the mud supports AMCP of some particular version. Note that Intermud file transfer is normally delivered via the OOB TCP port.

the second element is the router's address in the following format: " portnum".stack. 5. It has the following form: ({ (string) (int) (string) (string) (string) (string) (int) }) "shutdown". however.199. then the mud should close the connection and reopen to the designated router. If not. 0. if the restart_delay specifies a duration longer than 7 days.html The router_list is an array representing an ordered list of routers to use. 0 may be used to mean unknown/indefinite. 5. target_mudname. the first element is the router name. mudlist_id info_mapping // the router The info_mapping contains mud names as keys and information about each mud as the 0. Typically. then the router will mark the mud as "down" immediately rather waiting the 5 minutes. the mud will be deleted from the Intermud. The first element should be the router that the mud should use. and then as changes occur within the intermud network. originator_mudname. "199. For example: ({ "*nightmare".10 9000" }).122. this will happen once right after login (based on the old_mudlist_id that a mud provided in the startup-req-3 packet). If the restart_delay is greater than 5 minutes. This value is measured in seconds. Each element in the list is an array of two elements. The first router specified in the list will be the mud's preferred router. Any time less than 5 minutes will cause the router to operate as normal: it will wait for a while. originator_mudname. 0." then it can simply use 1 second for this. Typically. shutdown This packet is delivered to a mud's router when the mud is gracefully shutting down.Intermud-3: a Proposal for The Future restart_delay // the router restart_delay can be used to specify when the mud thinks it will be restarted. Future initial connections and startup-req packets will go to that router until told Note that this address can be passed to MudOS's socket_connect() function. target_mudname. A mud should remember the mudlist and its associated mudlist_id across reconnects to the router. 0. If a mud will be back "immediately. The list should be saved and used in case of failure to connect to a router. Likewise. this will be the router that the mud initially connected to. ({ (string) (int) (string) (string) (string) (string) (int) (mapping) }) "mudlist". mudlist The router will send this to a mud whenever the mud's list needs to be updated. This 20 of 27 6/28/2013 10:06 AM .

imud_tcp_port. 0.. The target mud may use this opportunity to actual open the OOB port and listen for the incoming connection request. This packet should only be delivered if the target mud does not support the auth service or if the service using the OOB connection will not require use of the auth service. then the mud has been deleted (it went down and has not come back for a week) from the Intermud. mud_type. 5. mudlib.Intermud-3: a Proposal for The Future http://mud. discussion required ### This packet is delivered to a target mud when an originating mud wishes to connect to its OOB port. base_mudlib. It is used to specify the authorization information for this connection. oob-begin This packet is used over an OOB link (see OOB Protocols). Since this packet operates over an OOB link. The packet has the following form: ({ (string) (int) (string) (string) (string) (string) }) "oob-req". player_port. 0. admin_email. ip_addr. Its format is: 21 of 27 6/28/2013 10:06 AM . target_mudname. open_status. If the mapping's value is zero.stack. state is an integer with the following values: -1 0 n mud is up mud is down mud will be down for n seconds oob-req ### not sure on this packet. The originating mud must then connect within 10 minutes. services other_data Each record of information should replace any prior record for a particular mud. it does not need to conform to standard packet driver. originator_mudname..html information is specified as an array with the following format: ({ (int) (string) (int) (int) (int) (string) (string) (string) (string) (string) (string) (mapping) (mapping) }) state. imud_udp_port.

7. The target mud delivers an oob-end packet if no deliveries are to be made. If authorization is not needed. The target should respond with various replies and acknowledgements during this process. then an oob-req packet is sent. it does not need to conform to standard packet formats. then it performs the deliveries.Intermud-3: a Proposal for The Future over the OOB link to the target mud. 2. Since this packet operates over an OOB link. originator_mudname. Target returns an oob-begin packet (with empty authorization information) to tell the originator to begin. If the target mud has any packets to deliver in an outbound queue for the originator. Originator connects to target's OOB port. Its format is: ({ (string) "oob-end". signalling completion. but specifying the mud should make this process simpler for some clients. The target mud validates the authorization tokens. This is used to simplify the process of determining which mud (of a possible many outstanding OOB connections) just completed their work. Originator delivers an oob-begin packet. Originator delivers an oob-end packet. or upon completion of the deliveries. This could be done simply by matching the socket which received the data to a record of what mud it connected to. containing the authorization tokens. 4. 6. Originator uses target's auth service to fetch necessary authorization tokens. then the target mud closes the connection. 3.stack. 9. auth_token The auth_type will contain one of the following values: 0 no authentication used 1 auth-mud-req used oob-end This packet is used over an OOB link (see OOB Protocols). 8. auth_type. ### more to come ### 1. This step operates of the in-band network. It is used to signify that a mud is done delivering packets to the other mud. If the validation fails. Originator delivers all queued packets to the target mud.html ({ (string) (string) (int) (int) }) "oob-begin". The originator should respond with various replies and acknowledgements during this process. The target is not yet allowed to actively send packets yet. 22 of 27 6/28/2013 10:06 AM . (string) mudname }) mudname states who has completing delivering packets. 5.

or vice-versa. There are two situations that will occur: a router will receive t1 before t2. Each router will also maintain a list of information about each Intermud channel. The other routers will install the change. Using the time across multiple machines with different time drifts and within different time zones and accounting for poor system administration can make the problem quite difficult. List Synchronization The two sets of lists are synchronized with the same scheme from a mud's point of view: they receive a unique token that precisely denotes the state of their list. Using the above formula for creating the token also ensures that a router will generate unique tokens even if they occur within the same second (the second token will be 1 more than the first). To guarantee uniqueness of the token. This link information will be used for routing around a failed link until the link is reestablished. Within the router network.t2). the information associated with each one. the router that originated the current token is remembered. A scheme is required to meet each of these problems. the routers can use the current time. First. Each router will also maintain a list of the status of all links in the router network. Now. it should not have to fetch the whole list). the type of channel. The originator drops the connection. This becomes complex because all routers must use the same token for the list (in case a mud is switched to a new router. if a router receives t1 before will have notified its muds with the t1-delta then with the t2-delta. If the originator has futher packets to deliver (some may have been placed in the originator's outbound queue during this process). The muds and the router will become stable with a current token of t2. 11. including the channel host/ record the new token. and the list of admitted/banned muds for the channel. Now. what happens when two routers generate deltas at about the same time? Call the tokens t1 and t2 and they are ordered as t1 < t2. Now. otherwise. some routers will have t1 and some will have t2). This is needed to uniquely identify deltas that occurred at the same instant. and maintain MUD mode TCP sessions with each of the other routers.html 10. The router network can remember how to provide deltas from one token to another or can just deliever complete lists when a request arrives from a mud that needs an update.Intermud-3: a Proposal for The Future http://mud. and propogate the information to their connected muds. the up/down/rebooting state. the stable-state token must be specified for this situation (it cannot simply be the last token to arrive. then the process returns to step #6. and which router the mud is connected to. The routers will create. This token will be passed with the list delta to all other routers. The rule is simply: final_token = max(t1. 23 of 27 6/28/2013 10:06 AM . time()). Assume a steady state where each router has the same token and a consistent list with respect to the other routers. let us say a router generates a delta to the list.stack. Each router will maintain a complete list of all muds on the Intermud. The target mud may time out and close the connection if it does not receive any packets for 10 minutes. It will create a new token as max(old_token + 1. then everything will be fine . open.

0. originator_mudname. the routers will route based entirely on the originator/target fields of the packet.solve case of two . list_delta_info "XXXlist-delta". it will ask for changes since t2 and receive none. 0. The t1-delta gets a new token applied to it and is recirculated through the router network. multiple packets? . "*". These can be ported/used 24 of 27 6/28/2013 10:06 AM .nl/intermud/intermud3. there should be a way to eliminate duplicates.html However. 5. 5. "*". the altered token will be set to t2+1. Knowledge of the packet types will not be required. ### info on routing around downed links ### There will exist two reference implementations of the mudlib side of the protocol.Intermud-3: a Proposal for The Future http://mud. most likely. Simply put: the t1-delta is subverted to using the t2 token and therefore does not uniquely identify the change. The routers will ignore the receipt of an altered-token-delta if its current token came from a similar altered-token. If the mudname refers to the router itself. Otherwise. two altered-t1-deltas could again create a synchronization problem. otherwise. originator_mudname. To overcome this. then the packet will be passed "up" to higher-level router processes.inductance handles rest ### ({ (string) (int) (string) (string) (string) (string) (int) (mapping) }) ({ (string) (int) (string) (string) (string) (string) (int) (mapping) }) "XXXlist-altered". If it is provided. then the packet will be sent to the mud if it is connected to the receiving router. This would seem to be okay unless a mud disconnected between the t2-delta and t1-delta notifications. the router for the mud is looked up and the packet is forwarded there. Rules for routing are based entirely on the target_mudname. token. ### todo: two packets with same time. Since many routers may see the conflict and initiate an alter-token operation. list_delta_info // the router // router broadcast // the router // router broadcast Packet Routing To efficiently implement the routing. This problem is solved with the use of a "alter-token" packet. then there will be problems. It will notify the muds with the t2-delta. When it reconnects. 0. then with the t1-delta. altered_token.stack. The router will deliver a token of t2 with the t1-delta change to the muds and will stabilize with that token. if the router receives t2 first. 0. This provides flexibility for extensions and. increased routing speed.

then a gateway will need to be written to hook into the router network and gateway the protocol between the MUD-mode TCP sockets and. etc) not-allowed : operation not allowed (e. Diku. This could involve moving away from the MUD-mode style of communication. MUCK. they will need to parse the incoming transmissions (MUD-mode is effectively a combination of save_variable() and a standard TCP socket).nl/intermud/intermud3.html to create implementations for alternate mudlibs and for MudOS pre-v21 drivers.g. The error_message is not as well defined at this point. etc). channel bans) Following is a list of standardized error codes that a mud may return: unk-type : unknown packet type (also sent by router) unk-user : unknown target user unk-channel : unknown channel name bad-pkt : bad packet format (also sent by router) tell : send a message to a remote user emoteto : send an emote to a remote user who-req : request a list of users on a remote mud who-reply : reply with a list of users on a remote mud finger-req : request finger information for a remote user finger-reply : reply with finger information for a remote user locate-req : request the location of a user locate-reply : reply with the location of a user chanlist-reply : reply with/update the list of available channels 25 of 27 6/28/2013 10:06 AM . For drivers without TCP sockets. at the wrong time.stack. Following is a list of the standard error codes returned by the routers: unk-dst : unknown destination mud not-imp : feature not yet implemented unk-type : unknown packet type (also sent by muds) unk-src : unknown source of packet (unregistered mud) bad-pkt : bad packet format (also sent by muds) bad-proto : protocol violation (packet used incorrectly. Note that it is possible for the router network protocol to evolve independently of the protocol used by the muds.g MOO. say. UDP. but should be something that can be displayed to the user.Intermud-3: a Proposal for The Future http://mud. Gateways can also be used for non-LP based muds (e. For drivers that have TCP but not MUD-mode. There are a "standard" set of error_codes that are returned by routers and remote muds in error packets.

news-grplist-req mail : deliver an item of mail mail-ack : acknoledge a mail file-list-req : request a list of files on a remote mud file-list-reply : reply with list list file-put : send a file to a remote mud file-put-ack : acknoledge a file-put file-get-req : get a file from a remote mud file-get-reply : reply with the requested file auth-mud-req : request a mud-level authorization token auth-mud-reply : reply with a mud-level authorization token ucache-update : update cached user information error : provide error information startup-req-3 : provide start up information to the router startup-reply : reply with/update the basic startup information (router list) shutdown : gracefully indicate shutdown mudlist : reply with/update the list of available muds oob-req : request setup for OOB connection oob-begin : begin OOB communication oob-end : end one side of an OOB process ### to be filled in with specifics ### Generally. Also. all the request/reply pairs can use a request key rather than recording actual user names (the user is associated with the request key on the originating mud).nl/intermud/intermud3. originator_mudname can almost always be ommitted since it can be inferred from the TCP session at the router end. channel-admin : adminstrate the participants of a channel chan-filter-req : filter a channel chan-filter-reply : return filtered channel messages to the router chan-who-req : request a who list for people listening to a channel on a remote mud chan-who-reply : return a requested channel who list channel-listen : tune a mud as a whole into or out of a channel chan-user-req : request channel user's info chan-user-reply : reply with channel user's info news-read-req : retrieve a news post from an OOB news server.html channel-m : send a message over a channel channel-e : send an emote over a channel channel-t : send a targetted emote over a channel channel-add : register a new channel channel-remove : remove a channel from name server databases. many of the fields will be replaced with numbers rather than full strings. news-post-req : post news to an OOB news server. 26 of 27 6/28/2013 10:06 AM .stack.Intermud-3: a Proposal for The Future http://mud. For example. Some of the fields can be paired up using various combined keys.

ucache services add section for OOB discussion added a couple more standard errors renamed some news packets to fit within the "news name space" add comments to mail.Intermud-3: a Proposal for The Future http://mud. December 20 add this change log update to startup-req-3 for the change in the locate-reply packet Winddle. removing local_fname and references to /ftp to remove some confusion. December 6 minor fix to mail fix TTL to be int in chan-filter-reply Winddle.html Deathblade. October 20 update to mail update to file fixed a few 'broken' links Deathblade. September 10 add some OOB from Winddle remove auth-user-xxx Deathblade. February 15 added section for contributors and implementors removed the section on reference implementations cleared up a couple OOB items Winddle. September 24 add typecasting Deathblade. August 9 added OOB information Deathblade. October 7 update to startup-req-2 modify the startup-req-2 packet and the mudinfo records to include "admin_email" and "other_data" add amcp service strip really old changelog entries Winddle. emoteto. and news protos re: auth service 27 of 27 6/28/2013 10:06 AM .stack. August 8 add the auth. file. January 7 update file.

Sign up to vote on this title
UsefulNot useful