I've been steaming away on developing support for the protocols I want my mud to support, and I've been increasingly interested in wanting to write an implementation of IMC2 for my mud. Since NM doesn't have something like that it'd be worth developing just on that token, to me, more toys the merrier, but I'm left with a few questions after reading the article about the protocol:
1] How is the "origin" tag specified? Is it just arbitrary? I would presume it's whatever MUD name I put into the form to join the network, but I don't really see much about that in the documentation.
2] To participate would this have to be something I have to be enabled by default? I recall some time ago (we're talking early nineties) one of the first MUDs I ever helped on the development side was trying to implement something like this with a few other MUDs, and the reason it fell through is that the main people developing it wanted that. The eventual aim of my MUD is to be fairly roleplay intensive; so while it is an option I'd like to have there for those interested I think it would be intrusive to the game atmosphere to have it enabled by default.
3] Regarding the IMC2 version, if I implement it to the specification on the page, what version would that be implementing it towards?
Having developed an imc2 client from the same design document I can say with certainty that these are some of the least nasty things you're likely to find.
1. Yes. Origin is the mud account currently logged in. The muds name.
2. Not sure what you mean. You can implement it any way you want. The protocol is notoriously agnostic about what and how it expects you to use it.
3. I don't know. I'm not sure if there even has been anything but undocumented ad hoc server changes. I'm going to guess its all 2.0. But does it really make a difference as to what you call it? The packet information wasn't updated. Many of them are useless or depreciated. Some just seem silly because of monkey patching. Some are undocumented.
22 Sep, 2010, David Haley wrote in the 3rd comment:
Votes: 0
IIRC, Crat's IMC2 server (dalet) makes a distinction between 2.0 and 2.1 re: line endings. Otherwise, I think it's all just 2.0, yes.
Having developed an imc2 client from the same design document I can say with certainty that these are some of the least nasty things you're likely to find.
That begs the question of what the most nasty things are.
2. Not sure what you mean. You can implement it any way you want. The protocol is notoriously agnostic about what and how it expects you to use it.
3. I don't know. I'm not sure if there even has been anything but undocumented ad hoc server changes. I'm going to guess its all 2.0. But does it really make a difference as to what you call it? The packet information wasn't updated. Many of them are useless or depreciated. Some just seem silly because of monkey patching. Some are undocumented.
As regards 2, it seems a silly thing to get hung up on to me as well, but people can be strange creatures. As regards 3, I'm not sure either, so I figured a good way to find out was to ask :)
David Haley said:
IIRC, Crat's IMC2 server (dalet) makes a distinction between 2.0 and 2.1 re: line endings. Otherwise, I think it's all just 2.0, yes.
Do you know or recall the differentiation?
Maya/Rudha
22 Sep, 2010, David Haley wrote in the 6th comment:
Votes: 0
Rudha said:
Do you know or recall the differentiation?
Sure: check out this post: [link=post]48093[/link]
Basically, 2.0 gives you broken but MB-spec-compliant line endings (\n\r), whereas 2.1 gives you correct line endings (\r\n).
So I suppose the important thing is to make sure you're sending the version string (and line endings) in accordance to the server you're connected to; thanks!
One of the lame things off the top of my head is undocumented finer details about the packet format.
It does a dikuesque practice without mentioning it. If the value to a key is a single word it has no quotes. If its many words it has quotes. And it may still have quotes for a single word. Needless to say I'd prefer a single standard and/or documentation.
Additionally the server sends random sharded packets which are incomplete or just undocumented. It expects the clients to filter/gracefully discern packets.
This leads to another problem. There's absolutely no guard against attacks over the network. The server simply echoes stuff along with little or no error detection.
These are just off the top of my head.
22 Sep, 2010, David Haley wrote in the 9th comment:
Votes: 0
The key=value format in IMC2 is absolutely terrible. :sad: As Runter said, the syntax depends on what the value is… it's maddening! Sometimes, even the order of the key/value pairs seems to matter…
It does a dikuesque practice without mentioning it. If the value to a key is a single word it has no quotes. If its many words it has quotes. And it may still have quotes for a single word. Needless to say I'd prefer a single standard and/or documentation.
Presumably on the client end you could just encapsulate everything in quotes, but I could see how that'd be a pain to figure out from the server packets.
Runter said:
Additionally the server sends random sharded packets which are incomplete or just undocumented. It expects the clients to filter/gracefully discern packets.
Well generally speaking if a packet is incomplete I should think it should be discarded and requested again; not 100% sure the client really gets a way to do that in all cases looking at the protocol though.
Runter said:
This leads to another problem. There's absolutely no guard against attacks over the network. The server simply echoes stuff along with little or no error detection.
That's … problematic. Even if individual nodes have sanity checks and safeguards against DoS style attacks and injection/etc there's still the issue that a server that lacks that could be brought down.
David Haley said:
The key=value format in IMC2 is absolutely terrible.
While I agree entirely, I'm kind of used to working with that kind of thing.
I agree, but I suppose there isn't much to be done for that on the client end.
Maya/Rudha
23 Sep, 2010, David Haley wrote in the 13th comment:
Votes: 0
Quote
That's … problematic. Even if individual nodes have sanity checks and safeguards against DoS style attacks and injection/etc there's still the issue that a server that lacks that could be brought down.
Well, on the other hand, if the server is so dumb that it just passes things around, it is less vulnerable to this kind of attack. To screw it up you'd have to mess with the things it has to parse, like destination MUDs for tells or something.
Quote
Well generally speaking if a packet is incomplete I should think it should be discarded and requested again; not 100% sure the client really gets a way to do that in all cases looking at the protocol though.
That would be reasonable (although a vector for DoS) but I don't think there is any ability to request packets again.
Quote
I agree, but I suppose there isn't much to be done for that on the client end.
Well, you're right that there's not much to be done. But Crat is more willing to make changes to the server, like fixing the MB line endings. So he might be amenable to only sending out data with quotes, and things like that. The nice thing about that particular change is that it's fully backwards compatible, unless client parsers are utterly brain-dead.
Well, you're right that there's not much to be done. But Crat is more willing to make changes to the server, like fixing the MB line endings. So he might be amenable to only sending out data with quotes, and things like that. The nice thing about that particular change is that it's fully backwards compatible, unless client parsers are utterly brain-dead.
That would probably be a positive and non-intrusive change if someone were to implement it.
It does a dikuesque practice without mentioning it. If the value to a key is a single word it has no quotes. If its many words it has quotes. And it may still have quotes for a single word. Needless to say I'd prefer a single standard and/or documentation.
Presumably on the client end you could just encapsulate everything in quotes, but I could see how that'd be a pain to figure out from the server packets.
I'm working on a client myself at the moment, and just ran into this quoted vs unquoted business. I assumed I could just quote everything and be done with it, but the server did something bizarre when I quoted text without spaces.
Two things here. Note how it has tacked on an escaped quote and a space to the text field, and note that the emote field lacks its value (should be zero). When I stopped quoting text without spaces it worked correctly.
Well, you're right that there's not much to be done. But Crat is more willing to make changes to the server, like fixing the MB line endings. So he might be amenable to only sending out data with quotes, and things like that. The nice thing about that particular change is that it's fully backwards compatible, unless client parsers are utterly brain-dead.
Seems like a good idea. If someone sends me an email it's more likely to wind up on the crat do list.
TBH I think it makes more sense to pick a non-printable character as a delimeter and bump up to 2.2.
Quotes is probably the easiest, unless we start making it like a TELOPT or something.
Maya/Rudha
I mean packet element delimeters. This kills a few birds with one stone:
- Arbitrary space parsing in text fields
- Pointlessly meaningful packet element order
- Spaces in mud and user names
Using some standard ASCII non-printable character as a delimeter is nowhere near as uselessly propeller-cap as shoehorning everything into your client's telopts handling.
I misunderstood you; when you said delimiter, I thought you meant for the strings, as opposed to the packets themselves.
The behaviour Caius describes is probably with looking into as well - I find it odd that the server would be adding that escaped quotes. As well, if you're not using emotes I don't see it being all neccesary to send them in the packet, though thats more of a pet peeve sort of concern than anything important.
I've been steaming away on developing support for the protocols I want my mud to support, and I've been increasingly interested in wanting to write an implementation of IMC2 for my mud. Since NM doesn't have something like that it'd be worth developing just on that token, to me, more toys the merrier, but I'm left with a few questions after reading the article about the protocol:
1] How is the "origin" tag specified? Is it just arbitrary? I would presume it's whatever MUD name I put into the form to join the network, but I don't really see much about that in the documentation.
2] To participate would this have to be something I have to be enabled by default? I recall some time ago (we're talking early nineties) one of the first MUDs I ever helped on the development side was trying to implement something like this with a few other MUDs, and the reason it fell through is that the main people developing it wanted that. The eventual aim of my MUD is to be fairly roleplay intensive; so while it is an option I'd like to have there for those interested I think it would be intrusive to the game atmosphere to have it enabled by default.
3] Regarding the IMC2 version, if I implement it to the specification on the page, what version would that be implementing it towards?
Maya/Rudha