05 Aug, 2009, Davion wrote in the 41st comment:
Votes: 0
ghasatta said:
Davion said:
The current way to handle the packets will be as follows.

packet_name field1:size=value field2:size=value field3:size=value\0
Great, I'm all for moving forward. Am I correct in understanding that the following is a potential valid packet?

imc3_msg sender:11=ghasatta@da channel:4=chat msg:80=omg I like this easy to parse format, my code can totally handle field:4=easy !!\0


That last one might need to be field:7=easy !!\0, but ya! You get the idea.
05 Aug, 2009, Tyche wrote in the 42nd comment:
Votes: 0
David Haley said:
Tyche said:
Why would you choose to annoy the user over the implementer?

Which user are you talking about? I thought that the IMC client would be the one escaping things before shipping them off to the IMC server; the MUD player would be no more aware that something happened than of the packet format in the first place.


You mean the certain fields in the packet are escaped when written and unescaped when read…. like SQL strings in certain clients, as opposed to the end user being forced to avoid the escape character. Okay, gotcha.
05 Aug, 2009, Kline wrote in the 43rd comment:
Votes: 0
So the entire packet will be \0 terminated, if I read this right? Any more specifics if all fields are treated as strings, etc?
05 Aug, 2009, Davion wrote in the 44th comment:
Votes: 0
Kline said:
So the entire packet will be \0 terminated, if I read this right? Any more specifics if all fields are treated as strings, etc?


Not sure if I quite get this, but I'll address it anyways! If you mean the field names/keys, than ya, they will be strings delimited by a ':'. This means field keys cannot contain the colon but oh well! That's not a problem at all. Also, with the strict packet handling the server will/does have, you wont have to worry about getting an incorrect size in a packet.

Edit: Right, and yes, delimit the entire packet with \0
05 Aug, 2009, Runter wrote in the 45th comment:
Votes: 0
Davion said:
Kline said:
So the entire packet will be \0 terminated, if I read this right? Any more specifics if all fields are treated as strings, etc?


Not sure if I quite get this, but I'll address it anyways! If you mean the field names/keys, than ya, they will be strings delimited by a ':'. This means field keys cannot contain the colon but oh well! That's not a problem at all. Also, with the strict packet handling the server will/does have, you wont have to worry about getting an incorrect size in a packet.

Edit: Right, and yes, delimit the entire packet with \0



Also the keys are all specification documented. There's no reason a : would ever be part of it. Eg, if a client was trying to make : part of the key then it wasn't an accepted key in the first place. (And it any packets that were formed like that would return a packet_error packet.)
05 Aug, 2009, ghasatta wrote in the 46th comment:
Votes: 0
Davion said:
That last one might need to be field:7=easy !!\0, but ya! You get the idea.

Davion, sorry, I didn't really explain what I was thinking. My example was a little flawed in that I made the "msg" param too long. I suppose this is actually a good illustration of the concern I was trying to raise. The intent was that the value for the msg param is "omg I like this easy to parse format, my code can totally handle field:4=easy !!" IMHO that will be nearly impossible to grok with the naked eye.

I was also trying to understand whether or not the whitespace is relevant in between the key/value pairs. I think the only conclusion that can be made is that whitespace is not relevant (er, not necessary?) in between key/value pairs, as the field length that is included with the field name is what a client will have to rely on when parsing a packet.
05 Aug, 2009, Davion wrote in the 47th comment:
Votes: 0
If the lengths are incorrect, the server will catch it as an incorrect packet and return an error packet to the MUD (not echo it to the rest of the MUDs). Remember part of this implementation involves stricter (actual?) error checking on the packets.

The white space is irrelevant and will simply be ignored between the pairs. It's only there to maintain a little human readability when examining the packages.
05 Aug, 2009, quixadhal wrote in the 48th comment:
Votes: 0
Only suggestion I'd have for this is to use:

packet_name:field_count field1:size=value field2:size=value field3:size=value

If you enumerate the number of fields, you don't need to loop until you find a special terminator character.
05 Aug, 2009, aidil wrote in the 49th comment:
Votes: 0
Obviously this is easy to generate and decode.

I wonder how you propose to send a list of items tho, such as, the list of available muds (with some data about each mud) or things like a who list.

You can send each item in its own field of course, but you either have to spend a field on a list length, or can only have one list in each packet and it has to be the last thing in the packet.

You can also decide to just pack them in a string, and only give a 'human readable' representation of such things.
05 Aug, 2009, quixadhal wrote in the 50th comment:
Votes: 0
You could pack it (here, using base64)…

mud_list:119 data1:77=bXVkX2xpc3RfZW50cnk6MyBuYW1lOjY9Rm9vTVVEIGlwOjk9MTI3LjAuMC4xIHBvcnQ6ND0zMDAw data2:27=tQnVnZ2VyIG9mZiwgZm9vbCE= … etc…

Then each entry could be unpacked, which would yield sub-packets like:

mud_list_entry:3 name:6=FooMUD ip:9=127.0.0.1 port:4=3000

Of course, that does obfuscate the data, as to debug it you'd have to unpack the fields, possibly several layers deep if the data being handled is nested. Not difficult, but it does mean you can't glance at the running log screen and see what's wrong right away.

You could also do something funky by adding more delimiters to indicate if the next thing is a raw key/value, or another nesting level. At that point though, you might as well just use YAML.

I don't know why there's such an aversion to libraries… It's far easier to download and build a library (if needed!) than to wade through custom code. It's not like one even has to bundle it (and in fact, if it's GPL'd, you may not be able to). I mean, I don't see glibc being "optional" for any MUDs written in C or C++.
05 Aug, 2009, aidil wrote in the 51st comment:
Votes: 0
quixadhal said:
You could pack it (here, using base64)…

mud_list:119 data1:77=bXVkX2xpc3RfZW50cnk6MyBuYW1lOjY9Rm9vTVVEIGlwOjk9MTI3LjAuMC4xIHBvcnQ6ND0zMDAw data2:27=tQnVnZ2VyIG9mZiwgZm9vbCE= … etc…

Then each entry could be unpacked, which would yield sub-packets like:

mud_list_entry:3 name:6=FooMUD ip:9=127.0.0.1 port:4=3000

Of course, that does obfuscate the data, as to debug it you'd have to unpack the fields, possibly several layers deep if the data being handled is nested. Not difficult, but it does mean you can't glance at the running log screen and see what's wrong right away.

You could also do something funky by adding more delimiters to indicate if the next thing is a raw key/value, or another nesting level. At that point though, you might as well just use YAML.


The problem with your proposal imho is that you need context for parsing, and are as a result mixing interpretation and parsing, or put differently, you can only parse a list if you know you are going to get a list, something you can only know by interpreting the partially parsed packet for its type/name.

While its quite possible to do, it seems a rather unclean way of doing this.

EDIT: While chatting about this for a bit, the following variation occured to me:

packet_name field1:-3=listitem1:4=test listitem2:5=test2…

So, a negative length denotes a list of -length items.

This would allow lists and scalars, and allows for nesting of lists, without needing knowledge of packet types etc to parse the format.
40.0/51