03 Mar, 2009, kiasyn wrote in the 81st comment:
Votes: 0
That feels so wrong, but I guess it works.
03 Mar, 2009, Scandum wrote in the 82nd comment:
Votes: 0
It's derived from the NEW_ENVIRON telnet option. Could be worse. :)

The server behaves a bit odd on more than one IAC DO MSSP per session, not entirely sure what it is, but I suspect it's the lame diku input handling.
03 Mar, 2009, quixadhal wrote in the 83rd comment:
Votes: 0
If you really want this to be useful and somewhat future-proof, why not have the initial handshake send a list of all the fields the server has data for, and then the client can ask for the ones they care about? Then it becomes a self-describing protocol, and most of the arguments of all these threads go away.

If the protocol were open and allowed one to send any key/value pairs desired, it would be up to the crawler to recognize them and ignore ones it doesn't want. As it stands, I'm shackled by the protocol itself, and can't give the crawler what it would use, since it's not defined in the specs. Since there's no way to ask for specific fields, I also can't include everything I'd want in the hopes that the crawler might pick it up, since EVERY connection from an MSSP-enabled client will have to get all of it, every time.

I initially wrote a lot more, but I think it would be more helpful to just have you go look at an entry on TMC and see how many fields would be empty because they aren't reflected in your spec, or because the data there won't fit in your structure (the ICON field, especially… true-color jpg/png graphics are the standard nowadays, and probably a bit larger than 32x32 pixels).

Just remember, MUD's are hobbies of love for most of us. The more rigid and picky this protocol is, the less likely it will be used. If you let the crawlers dictate what they require (and what they'll accept but not require), you push that responsibility out where it can be changed as needed without breaking the protocol itself. Just a suggestion.
03 Mar, 2009, Scandum wrote in the 84th comment:
Votes: 0
Well, it kind of got hammered in that it should be as simple as possible, and this is the result. The client can simply parse the fields it's interested in and ignore the rest.

The protocol does allow custom variables, the protocol simply defines a set of official variables.

The icon option is mainly geared toward zmud, and those are the icon requirements for it, maybe I got that wrong.

And as discussed earlier in this thread, I did suggest that the crawlers set the standard, to a degree. I looked at the TMC data set, and I was worried about ending up with so many default variables that it might become discouraging to add the protocol.
03 Mar, 2009, elanthis wrote in the 85th comment:
Votes: 0
That is a good stance. Especially given that it's a status protocol, and not a "here's a serialized representation of my entire game world" protocol… although a standard OLC protocol would be most hot. (And almost nearly impossible to develop in a truly MUD-neutral fashion.)
06 Mar, 2009, quixadhal wrote in the 86th comment:
Votes: 0
I was perusing the SocketMUD 2.3 code this morning, to see where and how they did telnet option handling, with the idea of adding MSSP support to it, and I noticed something that *might* break in the future. I'm posting it here, because I don't know if other codebases do things in a similar fashion, and I suspect this bug is somewhat unique to MSSP.

SocketMUD divides their input handling up between a read_from_socket() routine, and a next_cmd_from_buffer() routine. read_from_socket() does the raw byte pull from the descriptor and shoves it into an input buffer, preventing overflows along the way. next_cmd_from_buffer() actually parses chunks of said buffer and attempts to find the next valid entity the interpreter might care about. The telnet option handling is actually done by next_cmd_from_buffer(), which would be fine except for a shortcut taken in read_from socket(), namely, as it pulls from the socket, it stops reading if it sees a "\n" or "\r" at the end of the read result.

We can argue about how it's not good form to leave data in the system I/O buffer when you could have pulled it into local storage, but here's the potential bug. :)

Suppose someone adds a field to MSSP which holds multi-line data, such as the game's description, list of creators, whatever… The read routine will stop at each line break within the MSSP data field, and the command parser will not be able to either locate a command OR continue processing the telnet option, until enough times through the update loop go by for the entire option to be read into the buffer. That assumes the buffer will be large enough to hold it, as it might not be.

Just figured I'd shoot that as a heads up. I don't see it as a problem with MSSP, but it's a potential issue that might crop up as a side effect.
06 Mar, 2009, David Haley wrote in the 87th comment:
Votes: 0
The fact of the matter is that most MUDs' handling of telnet is rather broken because they look for lines, and don't treat it as a state machine. Really, every byte coming in should be passed through the state machine, and only added to the input buffer if the machine is in a certain state.
The state machine implementation is quite simple, for what it's worth. It might sound complicated, but it really isn't.
06 Mar, 2009, Mister wrote in the 88th comment:
Votes: 0
Most diku-derivatives read input not line-by-line but 'packet-by-packet'. A packet is received from the client, it's contents scanned and searched for 'IAC-stuff'. If a FULL request is found, it's processed. If only the first half is in that packet, and the second one in another packet… it's ignored (and chaos might ensue.)
As Ksilyan said, it should be a state machine. It's not hard to do, but requires some delving into the deepest entrails of the code.
06 Mar, 2009, Scandum wrote in the 89th comment:
Votes: 0
The way I set up the snippet, translate_telopts should be called right after a read() in merc for example:
for( ;; )
{
char bufin[MAX_INPUT_LENGTH];
int nRead;

nRead = read( d->descriptor, bufin, sizeof( bufin ) - 10 - iStart );
if( nRead > 0 )
{
iStart += translate_telopts(d, bufin, nRead, d->inbuf + iStart);

if( d->inbuf[iStart - 1] == '\n' )
break;
}


The snippet doesn't handle packet fragmentation, but client to server packet fragmentation is only a theoretical possibility, not a practical one, since only 3 bytes are send by a crawler. Even an extremely paranoid programmer should be able to live with those odds.
06 Mar, 2009, David Haley wrote in the 90th comment:
Votes: 0
In other words, your implementation is also wrong :smile:

Since you made such a fuss about implementing this properly for use by clients at any time, you should keep in mind that it is quite possible that a client would issue a subneg request in the middle of some other data transfer. So, you might not be sending just 3 bytes at a time.
06 Mar, 2009, Scandum wrote in the 91st comment:
Votes: 0
quixadhal said:
Just figured I'd shoot that as a heads up. I don't see it as a problem with MSSP, but it's a potential issue that might crop up as a side effect.

A MUD server doesn't read() a MSSP subnegotiation though, it only sends it.
06 Mar, 2009, Scandum wrote in the 92nd comment:
Votes: 0
David Haley said:
In other words, your implementation is also wrong :smile:

Yes, but only in a troll's vivid imagination.
06 Mar, 2009, David Haley wrote in the 93rd comment:
Votes: 0
Is it "unmanly" to implement a protocol correctly? :wink:
It's just funny to see you harp so much about elitism, proper implementation, stupid programmers and so on, and then wave your hands about an error in your implementation that is incidentally very simple to fix.
06 Mar, 2009, Scandum wrote in the 94th comment:
Votes: 0
I'm not gonna bother with a less than 0.01% chance of a screw up, but if you want to wear your tinfoil hat, be my guest.
06 Mar, 2009, David Haley wrote in the 95th comment:
Votes: 0
Don't let me catch you moaning about incompetent and stupid programmers who can't implement to spec properly again, then. :rolleyes:
06 Mar, 2009, quixadhal wrote in the 96th comment:
Votes: 0
Mister said:
Most diku-derivatives read input not line-by-line but 'packet-by-packet'. A packet is received from the client, it's contents scanned and searched for 'IAC-stuff'. If a FULL request is found, it's processed. If only the first half is in that packet, and the second one in another packet… it's ignored (and chaos might ensue.)
As Ksilyan said, it should be a state machine. It's not hard to do, but requires some delving into the deepest entrails of the code.


I wasn't speaking about most diku-derivatives, I was specifically showing how SocketMUD may break under the wrong circumstances, and warning that other servers might also share the same vulnerability. You are free to ignore said warnings, but if you end up kicking clients due to buffer overruns, this might be why…

Scandum said:
A MUD server doesn't read() a MSSP subnegotiation though, it only sends it.

When you chose to use TELNET negotiation, you opened the door to the fact that the protocol is designed so that client OR server can, at ANY time, perform any renegotiation they wish. Just because you only intend a server to send, doesn't mean a client can't do it. I agree, it shouldn't… but could and should are often miles apart in the real world.

I will repeat though, this isn't a problem with the protocol itself, but it's a problem that probably wouldn't show up unless someone implements it on SocketMUD or any server that also does shortcuts on unfiltered data.
06 Mar, 2009, Scandum wrote in the 97th comment:
Votes: 0
The protocol is very strictly defined in that regard, so a client doing that would not be following specs because IAC WILL MSSP is a server only command.

I've considered a two ended approach, but given there are 200 free telopts I figured it'd make more sense to grab a new number and make it the Mud Client Status Protocol if that ever becomes desirable.

David Haley said:
Don't let me catch you moaning about incompetent and stupid programmers who can't implement to spec properly again, then. :rolleyes:

I understand you like humping my leg like a horny little puppy, but it's starting to get old, especially when you have to fall back on ridiculous conjecture.
07 Mar, 2009, kiasyn wrote in the 98th comment:
Votes: 0
The MUDBytes crawler uses a state machine.

Also, play nice kids.
08 Mar, 2009, Scandum wrote in the 99th comment:
Votes: 0
Any news on the crawler?
09 Mar, 2009, kiasyn wrote in the 100th comment:
Votes: 0
// No comment.
80.0/154