GMCP in Aardwolf MUD

In a comment on the previous post regarding GMCP and MSDP in muds, I stated that “I do fully reserve the right to turn around in 2 weeks time and declare that I was completely wrong”. Well, this isn’t quite that, but close.

After experimenting more with GMCP and MSDP, I think I am going to move ahead with just GMCP. MSDP is a fine protocol and either could do the job, but there is already both CMUD GMCP support and Mudlet GMCP support out of the box. There is also a Mushclient GMCP plugin and a Tintin++ GMCP script already written.

Some of my earlier reasons to implement MSDP alongside GMCP are discussed below.

• Sending all data in a set even when only 1 or 2 items have changed is ineffecient:

  I’m not sure how much this ever mattered with MCCP, but assuming it does matter, the default GMCP implementation in CMud caches data. If you send values for ‘hp’ and ‘hpmax’ in one package, then later on only send a value for ‘hp’, the %gmcp.char.vitals.hpmax is still available in CMud.

  So, this leaves open the option to send:

  char.vitals { "hp": 44857, "mana": 50154, "moves": 41754, 
  "maxhp": 50159, "maxmana": 50154, "maxmoves": 41754 }

  Or if only two values have changed:

  char.vitals { "hp": 44850, "mana": 50153 }

  Mushclient can work the same way. Presumably in Mudlet this would be just a case of storing the data in a lua table.

  Making this assumption for GMCP puts more work back on the server side to track individual variable changes, but that was necessary for MSDP anyway.

• JSON is inefficient (compared to pure compiled C parsing binary data):

  This is probably still true looking at absolute numbers. However, after configuring Jansson in my local development port I was able to decode a JSON object with 9 attributes including a nested array and a nested object 125,000 times per second.

  By comparion, I can only view my equipment just under 20,000 times a second (it takes 51 microseconds). Seems performance on the server isn’t a concern after all for the types of message we will be receiving.

• The “standards” process itself didn’t go too well:

  Still true, still disappointed it didn’t work out better. Putting emotion aside, so what? It is what it is and looking forward it makes sense to go with the protocol with the widest client support.

• The protocol is “kind of” JSON:

  Another “so what?”. I wish this part of the discussion had been resolved, but it wasn’t. If a parser allows the other side to be a little less flexible with the standard it just doesn’t matter. As long as the parsers inside the clients accept the JSON we send, we’re good.

Once again, I want to be clear that there is nothing wrong with MSDP. It could just as easily do the job. I could sit here and flip-flop for weeks on which one to go with and neither would be “wrong”. It’s time to just pick something and move forward. GMCP has wider support and the initials concerns with it are lessened. There are other advantages outside of traditional MUD activities to supporting JSON, but that’s a different post sometime int the future.

For a preview of the work we have done on GMCP so far, check out GMCP in Aardwolf MUD. The arrangement of which tags are in which messages will almost definitely change, so please pay attention to that disclaimer.

This is also the best time to provide feedback – once people start to write plugins based on our tags it will be much harder to change them. At least unlike with the fixed format ‘statmon’, it will be easy to add to them without breaking existing scripts.