{stats}15/11,29/25,41/30,22/15,22/15,24/21
{stats}hp=15,maxhp=11,mana=29,maxmana=25,move=41,maxmove=30 …
{stats}15/11,29/25,41/30,22/15,22/15,24/21
{stats}hp=15,maxhp=11,mana=29,maxmana=25,move=41,maxmove=30 …
/* variables we need */
char* argv[32];
char* c = request_buffer;
size_t argc;
/* make sure buffer is not empty and does not end with a NUL */
if (request_buffer_size == 0 || request_buffer[request_buffer_size - 1] == 0)
return error_code;
/* parse args */
for (argc = 0; argc != 32 && c != request_buffer + request_buffer_size + 1; ++argc) {
argv[argc] = c;
c += strlen© + 1;
}
/* send the argument list off to your script language */
invoke_script_function("zmp_handler", argc, argv);
{stats}15/11,29/25,41/30,22/15,22/15,24/21
sword | 15gc | 1d4+4 | magic
axe | 16gc | 1d8+2 | plain
[b]sword[/b] (magic)
1d4+4 15gc
———————————
[b]axe[/b]
1d8+2 16gc
{roomdesc}
You are in a large room. Its walls are made of mud.
Inside the room are many uninteresting things.
Also the boss is there eyeing you off.
{/roomdesc}
There is no technical reason why they can't be that I can think. They all use different-enough "envelopes" that they shouldn't conflict on the wire.
I implement MCCP2 and various other TELNET and ANSI control codes along with ZMP with no problem. Totally orthogonal.
It has a lot to do with the server, too. If a server just blindly tries to start using all the protocols at once, bad and weird things may happen where they overlap. Were I to add MCP support to SourceMUD, for example, I would attempt to enable ZMP first, and if that fails, then attempt to enable MCP. I would never try to enable both simultaneously.
No, because such a feature is useless in ZMP.
<long-winded-explanation>
It's fairly useless in MCP, for that matter. If you are trying to use it as protection against man-in-the-middle style message injection attacks than it offers zero real protocol as the snooper can just get the key. I believe the real purpose of the session key in MCP is to provide a "secret" in each message so a malicious player cannot inject MCP commands into any input that gets sent to other players on a server with MCP parsing bugs. ZMP relies on the fact that commands are TELNET subrequests and so should not ever be spoofable by a client, because I naively assumed that all MUDs had proper TELNET handlers. I was obviously mistaken. I believe it is easier to have MUDs fix their TELNET handling than it is to ask them to implement key negotiation. If nothing else, all a MUD has to do is strip the IAC byte out of all player input and it becomes impossible to inject malicious ZMP commands into other players' connections. Compare to MCP, where a MUD would at the very least have to strip #$# from all player input (that isn't part of an MCP message itself) and even then might be vulnerable if the MUD ever prints # or #$ following by arbitrary player input (unlikely, but possible… especially if it happens to concatenate input received at different times). And compare to MXP which uses modes to determine if commands have any meaning or not, but which is likely going to run afoul when a developer wants to make marked-up text with player-provided text, for example when printing a "Greg said blah" line with marked-up player names or even highlighted player speech keywords.
It's worth nothing that if you make it possible for players to inject ZMP commands into the stream that you also are allowing player to inject other arbitrary TELNET commands into the stream, so a player could just as easily be an ass and trick a client into turning MCCP2 on or off without the MUD playing along, or freeze the terminal, or do any number of other bad things.
MUD servers also need to strip out byte 27 to avoid ANSI code injections, especially given that some ANSI codes can easily render a terminal unusable or crash some terminals outright. The terminal title string feature has a history of crashing a lot of popular terminal emulators when a long or unterminated title is provided.
I usually just escape things at output time (255 is after all a completely valid character code in most 8-bit encodings – it's y-umlaut in ISO-8859-1 for example), generally by having a small set of functions for adding data to the output buffer. MUD developers used to using sprintf or the like to mix in a ton of TELNET, ANSI, and text certainly need to completely sanitize data at input time, but my approach just requires me to use functions like:
connection->send_iac(EOR); // sends IAC <byte>
connection->send_negotiate(WILL, ECHO); // sends IAC <type> <opt>
connection->send_color(COLOR_RED); // sends \e
No, because such a feature is useless in ZMP.
<long-winded-explanation>
It's fairly useless in MCP, for that matter. If you are trying to use it as protection against man-in-the-middle style message injection attacks than it offers zero real protocol as the snooper can just get the key. I believe the real purpose of the session key in MCP is to provide a "secret" in each message so a malicious player cannot inject MCP commands into any input that gets sent to other players on a server with MCP parsing bugs. ZMP relies on the fact that commands are TELNET subrequests and so should not ever be spoofable by a client, because I naively assumed that all MUDs had proper TELNET handlers. I was obviously mistaken. I believe it is easier to have MUDs fix their TELNET handling than it is to ask them to implement key negotiation. If nothing else, all a MUD has to do is strip the IAC byte out of all player input and it becomes impossible to inject malicious ZMP commands into other players' connections. Compare to MCP, where a MUD would at the very least have to strip #$# from all player input (that isn't part of an MCP message itself) and even then might be vulnerable if the MUD ever prints # or #$ following by arbitrary player input (unlikely, but possible… especially if it happens to concatenate input received at different times). And compare to MXP which uses modes to determine if commands have any meaning or not, but which is likely going to run afoul when a developer wants to make marked-up text with player-provided text, for example when printing a "Greg said blah" line with marked-up player names or even highlighted player speech keywords.
It's worth nothing that if you make it possible for players to inject ZMP commands into the stream that you also are allowing player to inject other arbitrary TELNET commands into the stream, so a player could just as easily be an ass and trick a client into turning MCCP2 on or off without the MUD playing along, or freeze the terminal, or do any number of other bad things.
MUD servers also need to strip out byte 27 to avoid ANSI code injections, especially given that some ANSI codes can easily render a terminal unusable or crash some terminals outright. The terminal title string feature has a history of crashing a lot of popular terminal emulators when a long or unterminated title is provided.
I usually just escape things at output time (255 is after all a completely valid character code in most 8-bit encodings – it's y-umlaut in ISO-8859-1 for example), generally by having a small set of functions for adding data to the output buffer. MUD developers used to using sprintf or the like to mix in a ton of TELNET, ANSI, and text certainly need to completely sanitize data at input time, but my approach just requires me to use functions like:
connection->send_iac(EOR); // sends IAC <byte>
connection->send_negotiate(WILL, ECHO); // sends IAC <type> <opt>
connection->send_color(COLOR_RED); // sends \e[<color>m
connection->send_zmp(argc, argv); // sends IAC SB ZMP, then each string argument terminated with NUL and with any IAC escaped and NUL stripped, and then IAC SE
connection->send_text("foo bar blagh"); // sends text with IAC escaped to IAC IAC, \e stripped (no way to escape <Esc>, ironically enough), and \n replaced with \r\n
Since the only two places that player-provided input are ever put in the output buffer are both solid and safe, I never ever have to worry about a player injecting anything. I _also_ strip out \e and NUL at input time since they have no valid use. Double the protection is double-mint good!
But yeah, simplistic server code with broken TELNET handling need only strip IAC bytes from player input and ZMP has no need for extra special secret handshake stuff to protect against malicious input.
</long-winded-explanation>