Gitiles
Code Review Sign In
gerrit.morgengrauen.info / mudlib-public / 88f12479d30902b0d2c05be41901c96b92a88a77 / . / doc / concepts / intermud
blob: abe2b4ff6acf0858572905839f11a6bf006e9349 [file] [log] [blame]
MG Mud User88f12472016-06-24 23:31:02 +0200[diff] [blame^]1CONCEPT
2 intermud
3
4DESCRIPTION
5 There are several intermud protocols which define how (players on)
6 different muds can communicate with each other. The protocols are
7 in general not muddriver or mudlib dependant, though the number of
8 implementations is limited.
9
10 This text is about the rather old widely spread 'Zebedee Intermud',
11 which is also called 'Intermud 2' altough it differs quite a lot
12 from the real Intermud 2 protocol.
13
14 Full information on the newer Intermud 3 could be found on the
15 web at http://www.imaginary.com/protocols/intermud3.html so there
16 is no discussion here - the following is just about Zebedee Intermud
17 (aka Intermud 2).
18
19 Zebedee Intermud communication is handled by the /secure/inetd
20 object, originally written by Nostradamus for Zebedee with some
21 extensions that are discussed in inetd(C). How the data is
22 actually sent across the network is described in intermud.basic(C).
23
24SERVICES
25 Note that the fields "NAME" and "UDP_PORT" should be present in
26 every message. Very common are the fields "ID" (used whenever an
27 reply is expected) and "SND" (the sender: he should receive the
28 reply). These fields will not be mentioned in the list below.
29
30 Request types are listed on the leftmost row (e.g. "REQ=channel"),
31 associated header are listed indented.
32
33 "channel"
34 The channel-request is used for sending a message on any
35 channel. The "CMD" field is optional and may be omitted for
36 normal messages. Note that you should not send an history or
37 list request to _all_ known muds!
38
39 "CHANNEL"
40 The channel on which a message is send (the standard
41 channels are "intermud", "intercode", "interadm", "d-chat",
42 "d-code" and "d-adm"; on the d-channels German is spoken)
43
44 "DATA"
45 The message to be send (not used with history/list request)
46
47 "CMD"
48 The body of this header may be:
49 "" for normal intermud messages,
50 "emote" if the message is an emote/gemote,
51 "history" for an history request: the last 20 lines of
52 this channel will be shown.
53 "list" to list all remote users listening to this channel
54
55 "EMOTE" (optional)
56 The body is 1 if the message is an emote.
57 The body is 2 if the message is a gemote.
58
59 "finger"
60 Retreive information about a player or creator on a remote mud.
61
62 "DATA"
63 The player of whom information is requested
64
65 "locate"
66 Check whether a certain player is logged on at a remote mud.
67 This request is usually send to all known muds at the same time.
68
69 "user"
70 Name of the person who requests the information.
71 This is used by the sending mud only and has to be included
72 in the reply.
73
74 "vbs"
75 The verbose option has only two pre-defined values:
76 1 Even report when the result was negative
77 2 Don't do timeouts, but keep waiting
78 This is used by the sending mud only and has to be included
79 in the reply.
80
81 "fnd"
82 The found option is only used in the reply and it's value
83 is either 1 (success) or 0 (failure). The absence of a
84 found parameter indicates failure as well.
85
86 "DATA"
87 The player to find.
88
89 "man"
90 Retreive a manual page from a remote mud. Many muds don't
91 support this feature...
92
93 "DATA"
94 The name of the requested manual page
95
96 "mail"
97 An extension to the standard protocol, by Alvin@Sushi. This is
98 used to send mails from one mud to another.
99
100 "udpm_status"
101 This field should only be used in the reply and indicates
102 how mail is handled. Currently there are four pre-defined
103 values for the status field:
104 0 time out
105 1 delivered ok
106 2 unknown player
107 3 in spool (will be delivered later)
108
109 "udpm_writer"
110 Name of the person who wrote this mail
111
112 "udpm_spool_name"
113 Should be returned as sent, this value is used to remove
114 the mail from the spool directory after it has been
115 delivered (or refused)
116
117 "udpm_subject"
118 Subject of the mail message
119
120 "DATA"
121 The body of the mail (the actual message)
122
123 "ping"
124 A ping request has only the standard fields, the reply is
125 usually a short string like " is alive."
126
127 "query"
128 Get standard information about another mud. This is the only
129 command of which the reply may not include a load of rubbish,
130 but should only hold the requested information, so that it can
131 be parsed by the server.
132
133 "DATA"
134 The following queries are pretty much standard:
135 "commands" List all commands that are supported by the inetd
136 "email" The email-address of the mud administrator(s)
137 "hosts" A listing of all hosts in a special format [t.b.d.]
138 "inetd" The version number of the inetd used
139 "list" The list of all items which can be queried
140 "info" A short human-readable string with practically
141 "query" information
142 "mud_port" The portnumber that players connect to on login
143 "time" The local time for this mud
144 "users" A list of the people that are active in this mud
145 "version" The version of the mud-driver (and library)
146 "www" The URL of the mud's web page (e.g.
147 http://mud.stack.nl/)
148
149 "reply"
150 This request method is used for _all_ replies.
151
152 "DATA"
153 A human-readable string, containing the reply to a given query
154
155 "RCPNT"
156 The same name as in the "SND" field or the query; Usually
157 this is the name of the player who initiated the query
158
159 "QUERY"
160 This field is only used in a response to a "query" request
161 and should be equal to the "DATA" field of that request
162
163 "vbs"
164 This field is only used in a response to a "locate" request
165 and should be equal to the "vbs" field of that request
166
167 "user"
168 This field is only used in a response to a "locate" request
169 and should be equal to the "user" field of that request
170
171 "fnd"
172 This field is only used in a response to a "locate" request
173 and should be 1 if the player was located and 0 otherwise
174
175 "tell"
176 Say something to a player on another mud.
177
178 "RCPNT"
179 Name of the player to whom you are talking
180
181 "DATA"
182 Whatever you wish to say to this person
183
184 Optional emote-tos are handles are also handled as tells, so
185 muds without emote-to support display them as reasonable readable
186 tell message.
187
188 "RCPNT"
189 Name of the player to whom you are talking
190
191 "METHOD"
192 The body of this header may be:
193 "emote" if the message is an emote
194 "gemote" if the message is a genitiv emote
195
196 "DATA"
197 The text to be emoted prepended with "*" and appended
198 with "* ". If you display the emote you have to cut the
199 stars off. Muds that do not process emote-tos display the
200 emote as tell message with the stars as indication of
201 the message's emote meaning.
202
203 "who"
204 List the people that are active on a remote mud. The anwer
205 usually contains some active information about the players,
206 like titles, levels or age.
207
208 "DATA"
209 Not supported by many muds. Introduced August 1997.
210 Additional switch(es) (blanc separated) that change the
211 appearence of the resulting list. The switches normally
212 resemble the switches used inside of that mud for the 'who'
213 command. Typical values include:
214 "short" "s" "-short" "-s" "kurz":
215 Return a concise listing.
216 "alpha" "a" "alphabetisch" "-alpha" "-a"
217 Sort the players alphabetically.
218
219AUTHOR
220 Information taken from Outerspaces documentation to be found
221 on http://mud.stack.nl/intermud/
222
223SEE ALSO
224 inetd(C), intermud.basic(C), imp(C)