Scandum
Wizard
Group: Members
Posts: 1,105
Joined: Aug 8, 2006
|
#76 Posted Mar 3, 2009, 3:04 am
|
Kline said:So any technical arguments aside, this is fairly off-putting for me (and maybe others? I don't know) to even care to implement just due to attitude about things so far, Scandum. I'm not trying to troll, flame, or whatever, just be honest. You have an idea for a protocol, and I like it, it sounds cool and would be something neat and help keep index sites more up-to-date if they implement it -- awesome so far! Yet...You want feedback and suggestions but continually stick to your guns of "Well it's my idea. I'm doing it my way. I've already added it into TinTin because I can. Now my way has even more virtue of being the right way, because a client is already supporting it."
And while you expect MSSP to replace all manual updates -- can you really enforce that? I can see the argument of both sides, replacing or supplementing, but I don't know many people who would be willing to run a site that gets populated with automated data without review/intervention; reliable as it may be.
I have listened to advise however and I think the protocol has come a long way. I've also pointed out from the start I'm willing to put in the work instead of just doing the talk.
Things are however problematic if I fundamentally disagree with a position.
Keep in mind that I originally wanted to implement MSSP as DH and elanthis are suggesting now, so it's not so much that I'm sticking to my guns, but considered the options and changed my mind, it doesn't help when there are no good logical arguments against a position, other than "I think people will react in this or that fashion and it won't be good". TMC currently has unreviewed updates, it seems to work so far.
|
|
|
kiasyn
Wizard
Group: Administrators
Posts: 857
Joined: May 15, 2006
|
#77 Posted Mar 3, 2009, 3:37 am
|
Either your test server or the spec you have defined is incorrect.
Code (text): 1
2
3
4
5
6 |
MSSP_VAL 1
MSSP_VAR 2
|
these values should be the other way around:
Code (text): 1
2
3
4
5
6 |
MSSP_VAR 1
MSSP_VAL 2
|
|
......................... 
|
|
|
|
|
|
|
|
|
|
|
|
quixadhal
Wizard
Group: Members
Posts: 1,256
Joined: Oct 17, 2007
|
#83 Posted Mar 3, 2009, 4:07 am
|
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.
|
......................... 
|
|
Scandum
Wizard
Group: Members
Posts: 1,105
Joined: Aug 8, 2006
|
#84 Posted Mar 3, 2009, 4:18 am
|
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.
|
|
|
elanthis
Wizard
Group: Members
Posts: 760
Joined: Feb 26, 2008
|
#85 Posted Mar 3, 2009, 9:52 am
|
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.)
|
|
.........................
Cutting corners to keep your line count down is just sad.
|
|
quixadhal
Wizard
Group: Members
Posts: 1,256
Joined: Oct 17, 2007
|
#86 Posted Mar 6, 2009, 1:18 pm
|
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.
|
.........................
|
|
|
|
Mister
Apprentice
Group: Members
Posts: 34
Joined: Aug 20, 2007
|
#88 Posted Mar 6, 2009, 1:40 pm
|
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.
|
|
|
Scandum
Wizard
Group: Members
Posts: 1,105
Joined: Aug 8, 2006
|
#89 Posted Mar 6, 2009, 2:02 pm
|
The way I set up the snippet, translate_telopts should be called right after a read() in merc for example:
Code (text): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 |
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.
|
|
|
|
|
