21 Sep, 2010, Rudha wrote in the 1st comment:
Votes: 0
Hi there,

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
22 Sep, 2010, Runter wrote in the 2nd comment:
Votes: 0
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.
22 Sep, 2010, Kline wrote in the 4th comment:
Votes: 0
David Haley said:
IIRC

You do. :)
22 Sep, 2010, Rudha wrote in the 5th comment:
Votes: 0
Thank you all for the replies:

Runter said:
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.

Runter said:
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).
22 Sep, 2010, Rudha wrote in the 7th comment:
Votes: 0
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!

Maya/Rudha
22 Sep, 2010, Runter wrote in the 8th comment:
Votes: 0
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…
22 Sep, 2010, Rudha wrote in the 10th comment:
Votes: 0
Runter said:
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.

Maya/Rudha
22 Sep, 2010, Runter wrote in the 11th comment:
Votes: 0
It complicates the parser when the server sends you data in multiple ways.
23 Sep, 2010, Rudha wrote in the 12th comment:
Votes: 0
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.
23 Sep, 2010, Runter wrote in the 14th comment:
Votes: 0
I wouldn't assume anything good about the freedom client. But yeah, my guess is it also uses the diku string read function.
23 Sep, 2010, Rudha wrote in the 15th comment:
Votes: 0
David Haley said:
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.
26 Sep, 2010, Caius wrote in the 16th comment:
Votes: 0
Rudha said:
Runter said:
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.

I sent this, where the text field is quoted:
Client said:
Caius@TestMud 1285465906 TestMud ice-msg-b *@* channel=TestSrv:iChat text="wtf?!?!?!" emote=0 echo=1


So far so good. But the server sent this back to me:
Server said:
Caius-TestMud@TestSrv 1285465917 TestSrv ice-msg-b *@TestMud text="wtf?!?!?!\" " channel=TestSrv:iChat sender=Caius@TestMud emote=


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.
26 Sep, 2010, Cratylus wrote in the 17th comment:
Votes: 0
Quote
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.

-Crat
http://lpmuds.net
26 Sep, 2010, Rudha wrote in the 18th comment:
Votes: 0
Quotes is probably the easiest, unless we start making it like a TELOPT or something.

Maya/Rudha
26 Sep, 2010, Cratylus wrote in the 19th comment:
Votes: 0
Rudha said:
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.

-Crat
http://lpmuds.net
26 Sep, 2010, Rudha wrote in the 20th comment:
Votes: 0
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.

Maya/Rudha
0.0/56