28 Feb, 2009, Scandum wrote in the 41st comment:
Votes: 0
quixadhal said:
In other words, why must the server be the one doing the sending? Why not let it wait for the client to ask for it? Just because the client agreed that it wants to do MSSP, doesn't mean it has to do it right then and there.

This is for crawlers right, are you suggesting that a crawler connects, then waits 1 to 5 minutes till it's done scratching its ass, then asks for the data?

I get the feeling you're coming up with ridiculous nonsense just to be argumentative.

elanthis said:
Aside from the stupidity of only sending data based on something like day of week (what if the MUD was down Sunday?), the fact that you don't even have a well-defined use case for the feature is 100% absolute undeniable proof that the feature should not exist.

I'm not following you, the protocol needs to define what is to be expected if an option is omitted. Either the value is expected to be false, or it's expected to use a previously submitted value, if any. There's no use case to it.

The advantage of omitting false or unused values is that it'll cut down on the amount of data traffic. The disadvantage is that muds can't implement smart behavior to send a minimum amount of data, and that it's more difficult to implement for the trackers.

Regarding the mud being down on Sunday, it'll probably be up the next Sunday. No brainer responses like these are really starting to suck the fun out of this for me and I'll make a conscious effort to ignore them from now on.
Quote
No, not at all. If the MUD is no longer on bobmud.com 4321, then the client will attempt to connect and the connection will fail, and it will never be able to get the MSSP data telling it where the new address is. The only way this works is if somebody leaves an empty temp server running on the old host or port (rare in the MUD world, as a move usually implies that the old account was lost), or if they somehow have it listening on both ports (most MUDs cannot do that, and almost no hosts will set up DNAT for it).

If this is the case you'll need to manually edit your site listing, not the end of the world. A good crawler site will allow you to edit the information and send a confirmation email to the admin email address to update the changes.
28 Feb, 2009, Scandum wrote in the 42nd comment:
Votes: 0
Added a new variable:
"INTERMUD"           "I3", "IMC2", "AberChat", "MushLink", "MudNet", "Etc". Omit or use an empty string if not applicable.
28 Feb, 2009, quixadhal wrote in the 43rd comment:
Votes: 0
Scandum said:
quixadhal said:
In other words, why must the server be the one doing the sending? Why not let it wait for the client to ask for it? Just because the client agreed that it wants to do MSSP, doesn't mean it has to do it right then and there.

This is for crawlers right, are you suggesting that a crawler connects, then waits 1 to 5 minutes till it's done scratching its ass, then asks for the data?

And just how is your protocol supposed to tell the difference between a crawler (which would want the data immediately), and a MSSP-enabled client (which may want to get such info, but probably not EVERY time the poor player wants to connect)? At the point you're forcing the negotiation, there's no way to tell anything beyond "Yes, I understand MSSP".

Assuming a crawler wants to implement this, would it really HURT to have them be the one to say "Ok, I'm ready to get data"?
28 Feb, 2009, elanthis wrote in the 44th comment:
Votes: 0
Scandum said:
I'm not following you, the protocol needs to define what is to be expected if an option is omitted. Either the value is expected to be false, or it's expected to use a previously submitted value, if any. There's no use case to it.


You have just provided two different solutions. You must pick one. You must have a reason for picking one over the other. The use case for "omitted means nothing" is clear: the data is irrelevant or not available, even if it was before. The use case for "use last value" is very unclear: there is little reason to save a few dozen bytes of bandwidth while complicating the implementation of servers and clients by requiring extensive state tracking or scheduling.

Another legitimate problem with omitted meaning use-last-value is that there is the no clear way of saying "this value is no longer meaningful, forget about it entirely." The server is required to keep a place-holder with an empty string value in the output for a few months just to make sure all the crawlers definitely delete the stored value.

Quote
Regarding the mud being down on Sunday, it'll probably be up the next Sunday. No brainer responses like these are really starting to suck the fun out of this for me and I'll make a conscious effort to ignore them from now on.


Your solution means clients having to stick with two weeks of stale data due to what could have been just a small blip of outage, all for the sake of saving a handful of bytes of traffic for requests made every 5 minutes at most (which is NOTHING compared to the player traffic of the MUD on any remotely popular server).

The irony is that you claimed my raising the issue was a no-brainer when it's entirely obvious that you applied absolutely no real thought to your response. :/

We aren't coming up with reasons to stop you from having your status protocol. We're trying to help you avoid bad decisions and make a better protocol. You've put like 3 days of thought into this and are getting offended that we don't think the first draft is rock solid. Calm down and try having an actual dialog instead of just sticking your fingers in your ears and going "nyah nyah nyah you guys are dumb i'm the smartest nyah nyah nyah." You can either actually take advantage of the criticism and spend real time thinking about them and solving the problems, or you can keep on giving me more material for a DailyWTF.com post. One of those two is going to be of far greater benefit to both yourself and the rest of the community.

If we thought the whole idea was dumb or that you were dumb, we wouldn't be spending so much time and effort offering our expertise (easily over a combined century of real-life network-oriented software development between just a handful of the more verbal participants in this thread) for your edification. We'd just make fun of you and then ignore you. Heck, you've got both KaVir and Tyche commenting – more than once – which alone is almost a small miracle… ;)

Quote
If this is the case you'll need to manually edit your site listing, not the end of the world. A good crawler site will allow you to edit the information and send a confirmation email to the admin email address to update the changes.


Of course. The original point was that there is little reason for MSSP to advertise that kind of information given that you'll need to manually resubmit it in 99% of the cases where that information changes. Minor point overall. :)

quixadhal said:
And just how is your protocol supposed to tell the difference between a crawler (which would want the data immediately), and a MSSP-enabled client (which may want to get such info, but probably not EVERY time the poor player wants to connect)?


Why do we care? The player would not be adversely impacted at all. The MUD is going to spit out a banner and then it will do nothing for at least several seconds while a player logs in, so even if MSSP were to generate 100KB of data, the player isn't likely to notice in the least.
28 Feb, 2009, elanthis wrote in the 45th comment:
Votes: 0
Scandum, instead of going back and forth on minor points, here's a break-down of the large problems I see with MSSP that you have yet to address satisfactorily:

Complexity of Implementation: The specification thankfully stayed the hell away from the structured data mess and has remained relatively simple. However, from experience with ZMP, I suggest that you aim for using a pure-text output format that does not rely on binary codes, as the current protocol does. Scripting languages are very popular and a very solid choice for implementing a crawler, but many such scripting languages are surprisingly difficult to use with binary data compared to pure textual data (unlike C, which is just hard to use with both :p ). Using plain-text delimiters will make implementing the protocol significantly easier. Removing the use of TELNET entirely makes it easier still, as then a client can be implemented without using ANY binary data… they can open a text stream on the socket, spit out a line, and then use the languages built-in line-at-a-time buffered reader to parse your data. I have lots of real-life experience with this particular issue.

Stateful Protocol: The idea of compressing output by only sometimes sending a full set of data forces the protocol to become stateful. Especially given how popular RESTful protocols are these days (popular specifically because they are stateless) it seems silly to intentionally add language making the protocol stateful when it already works 100% in a stateless manner. Add on to that the fact that the compression gained by this behavior is entirely and absolutely without worth in the age of pervasive broadband speeds and multi-Gigabyte bandwidth caps on even the worst of ISPs, compounded with the fact that MSSP can quite easily be used with MCCP. I firmly believe that making the protocol stateful is very detrimental, as it severely complicates crawlers and is nothing more than a bait-and-switch to server developers, offering a neat idea of "reduced bandwidth" and then giving them headaches dealing with ensuring that crawlers always have accurate data.

TELNET vs Web: What real-life advantages does a TELNET status protocol have over RDF? I've heard only two. The first is that some MUDs have no website, which I call shenanigans on unless someone can actually prove that there is a MUD with a real playerbase and no Web presence at all. The second is that the TELNET implementation makes it easier to have real-time statistics, which I question the usefulness of given that the end consumers of the data won't be seeing real-time statistics anyway. I have give a few (admittedly very minor) advantages for an RDF-based protocol as well. I am not saying that TELNET is clearly wrong, not at all; I simply would like to see a solid, well-stated case made on how it is preferable to reusing existing, extensible, Web-based technologies designed for exactly this sort of use.

Extensibility: What resources are available for maintaining a list of known variables and their meanings once the initial spec is out? Should namespacing of keys be explicitly mentioned in the spec so that variables specific to certain classes of MUD (e.g. Diku) can be clearly defined as such and also allow future MUD families to get safely define new variables without fear of a collision with another family's variables?

I think that covers the major issues both myself and others have brought up.
28 Feb, 2009, David Haley wrote in the 46th comment:
Votes: 0
elanthis said:
The first is that some MUDs have no website, which I call shenanigans on unless someone can actually prove that there is a MUD with a real playerbase and no Web presence at all.

Maybe small MUDs that don't have a playerbase yet but want to get one, and to do so want more exposure, want to be consumers of this listing protocol too…

elanthis said:
Should namespacing of keys be explicitly mentioned in the spec so that variables specific to certain classes of MUD (e.g. Diku) can be clearly defined as such and also allow future MUD families to get safely define new variables without fear of a collision with another family's variables?

Actually, that's a pretty good idea. You now have the problem of who "owns" the standard and therefore gets to decide on new families should they come up, but that's a social problem, not a technical one.
28 Feb, 2009, Scandum wrote in the 47th comment:
Votes: 0
elanthis said:
However, from experience with ZMP, I suggest that you aim for using a pure-text output format that does not rely on binary codes, as the current protocol does.

Can you name one scripting language that cannot handle control and 8 bit characters? The problem of ZMP is that it uses NUL bytes which makes it tedious to implement in string based languages. MSSP doesn't have that issue, and I think the protocol currently states that NUL and IAC are not allowed within variables and values. As it is there are roughly two hundred muds that have a partial telnet implementation, and it seems the logical route to take since it's peanuts inserting MSSP in a well written telopt handler. Unless you can provide good evidence that \c-a and \c-b and \xFF are hard to handle in popular scripting languages, there's no difference between <var>:<val>\r\n and \c-a<var>\c-b<val>.

elanthis said:
Stateful Protocol:The idea of compressing output by only sometimes sending a full set of data forces the protocol to become stateful.

I definitely don't want omitted values to automatically be assumed zero because that'll make it quite difficult for crawlers. I guess I should emphasis in the protocol that 1Kb of data is so minimal that there's no need for compression of any kind.

elanthis said:
I simply would like to see a solid, well-stated case made on how it is preferable to reusing existing, extensible, Web-based technologies designed for exactly this sort of use.

The mud crawlers are already up and running. I think that's the main advantage, they don't need an extra url, just check for IAC WILL MSSP, send back IAC DO MSSP, and check for IAC SB MSSP <stuff> IAC SE. Telnet clients will simply ignore the IAC WILL MSSP, like they blissfully ignore IAC WILL MCCP.

elanthis said:
What resources are available for maintaining a list of known variables and their meanings once the initial spec is out?

TinTin++ will support MSSP which will provide a standard for debugging mud servers wanting to support MSSP, and I can keep a page up to date on the tintin site as well. I think that should be enough to keep things organized for a while.
28 Feb, 2009, Scandum wrote in the 48th comment:
Votes: 0
David Haley said:
You now have the problem of who "owns" the standard and therefore gets to decide on new families should they come up, but that's a social problem, not a technical one.

Mud sites that adopt it will likely further develop the standard.
28 Feb, 2009, David Haley wrote in the 49th comment:
Votes: 0
Scandum said:
Mud sites that adopt it will likely further develop the standard.

So we'll have a whole bunch of competing versions with their own definitions – sounds great! :wink:
28 Feb, 2009, Scandum wrote in the 50th comment:
Votes: 0
That's the main reason to get a decent set of base variables. But from the lack of suggestions I assume that part is covered.
28 Feb, 2009, David Haley wrote in the 51st comment:
Votes: 0
I think you missed the point. There will inevitably be things that we miss here, if anything due to the obvious fact that things will change as time goes on. The idea of every crawler site having free reign to redefine everything in their own way to suit changes sounds like a Rather Bad Idea (TM).
01 Mar, 2009, elanthis wrote in the 52nd comment:
Votes: 0
Scandum said:
Can you name one scripting language that cannot handle control and 8 bit characters? The problem of ZMP is that it uses NUL bytes which makes it tedious to implement in string based languages.


I said "easy relative to dealing with text" and not "cannot do it at all." Don't overestimate the average idiot, either. If it's harder than dead simple, it's too hard. Seriously. I have very real experience with this, dude. There really is a difference between ':' and '\x01' when it comes to the average coder. One is something they "get" right off the bat. The other is something most don't even know is possible. Most MUD coders do not even truly understand the fundamentals of either general software development nor the specifics of their language's syntax and standard library. When it comes to MUDs, aim for the least common denominator.

It is overall a minor point. I wholeheartedly believe the protocol will have higher uptake if you follow my advice, but using the non-textual codes won't cause it fail entirely.

Quote
MSSP doesn't have that issue, and I think the protocol currently states that NUL and IAC are not allowed within variables and values.


That's fine.

Quote
I definitely don't want omitted values to automatically be assumed zero because that'll make it quite difficult for crawlers. I guess I should emphasis in the protocol that 1Kb of data is so minimal that there's no need for compression of any kind.


If zero means something different than the empty string, then yes, this is true. Omitted should mean "there is no value for this at all, nothing meaningful, do not display it or index it or anything, because this value does not exist." That is a very, very, very different thing than "use the last value you saw."

A clear example of my issue with your proposed behavior: a put up a Diku-derived MUD. I add MSSP, and add a number of Diku-related MSSP variables. After a couple years I put up my rewrite (built off of SocketMUD). None of the Diku-related variables make sense in my new codebase, so I clearly didn't add them to the new codebase's MSSP implementation. Frustratingly, however, all of the MUD crawlers keep listing those values in my MUD's entry, because the spec says that the crawlers have to use the last value if I don't omit a variable. I have to add cruft to my new shiny MUD to work around the protocol to force crawlers to forgot variables sent by an entirely different codebae.

If omitted variables means "does not exist, do not use" then the problem goes away. The new codebase does not send those variables. The crawlers simply delete all prior data when reading in an MSSP block from a MUD. Each MSSP request should list all relevant data every time, so neither the server nor the crawler has any reason to care in the least about what got sent last time – either the data got sent with the new result or the MUD developer decided that the data become irrelevant and removed it. The crawlers will be easier to implement, too.

I cannot stress this enough. The "use last value" behavior is WRONG and BAD and KILLS BABIES. Don't do it.

Quote
The mud crawlers are already up and running.


Good enough for me.

Is there a list of known crawlers?

Quote
TinTin++ will support MSSP which will provide a standard for debugging mud servers wanting to support MSSP, and I can keep a page up to date on the tintin site as well. I think that should be enough to keep things organized for a while.


Alright. I would think about getting it somewhere with a dedicated forum asap, as at least then MUD authors have a standard place (referenced in the specification) to go to for informally hashing out extensions. Obviously it would be neat to have someone formalizing those specs, but just being able to easily look up what other people are using in their extensions is really good enough for the most part.

I would also just recommend clearly stating in the spec that custom variables should have namespacing. The semi-official ones might just use a simple DIKU. prefix or the like. MUD-specific ones should probably be recommended to use their game hostname or something, e.g. COM.HOSTSITE.MYMUD.VARIABLE. The clearer you spell out "good practice" the more likely people will actually follow it.
01 Mar, 2009, Scandum wrote in the 53rd comment:
Votes: 0
elanthis said:
Is there a list of known crawlers?

Not really. I know that mudstats and tmc have one up and running.

elanthis said:
Alright. I would think about getting it somewhere with a dedicated forum asap, as at least then MUD authors have a standard place (referenced in the specification) to go to for informally hashing out extensions. Obviously it would be neat to have someone formalizing those specs, but just being able to easily look up what other people are using in their extensions is really good enough for the most part.

Best left to the crawler sites in my opinion. Adding pre-fixes is just gonna be annoying.
02 Mar, 2009, Scandum wrote in the 54th comment:
Votes: 0
Moving this here so there is somewhat of an announcement topics.

David Haley said:
So you have completely settled on the idea of using telnet options, have you?


Given how dumbed down MSSP currently is it's just telnet compatible. The clearest advantage is that the MUD server can announce that it uses MSSP to any client. This isn't possible without being annoying with the alternative protocols suggested which makes it unaccessible to mud clients that want to automatically and transparently set up connection information.

And as observed before, there's no difference other than that it uses \x01 \x02 and \xFF instead of : \r and \n.

The argument that it's easy to plug-in into muds with a telnet handler has been ignored as well, opposed to the hack job that a different implementation would imply.
02 Mar, 2009, David Haley wrote in the 55th comment:
Votes: 0
Out of curiosity, who all here except for Scandum thinks that the telnet options are the way to go? Just trying to get a feel for the consensus – if I'm the only one who thinks they're a bad idea, …
02 Mar, 2009, quixadhal wrote in the 56th comment:
Votes: 0
I've already voiced my opinions on the matter. It's Scandum's protocol, and we'll have to see how well it's adopted by the mud listing sites. All I ask is that it be tested with horribly broken clients (such as the pervasive windows telnet client), so it doesn't cause anything to blow up that doesn't already blow up. :)
02 Mar, 2009, David Haley wrote in the 57th comment:
Votes: 0
Well, we can either treat this as somebody's personal baby, or we can treat it as something that would actually be useful to the community. If people actually care about this being valuable to everybody, you need the latter. If people are just giving opinions to give opinions, then sure, who cares, go with the former.
02 Mar, 2009, Scandum wrote in the 58th comment:
Votes: 0
It works fine with windows telnet.

If MSSP fails I've at least tried something that tried to raise the bar, rather than lowering it. I've got a mud snippet ready, but waiting fom feedback from TMC and TMS. I'm hoping Lasher is interested in playing the 'who has the most players on' game. I've also got a test mud ready that supports MSSP.

I think it'll pretty much stand or fall with a mud directory supporting it and promoting its use. If it connects 8 to 12 times a day and shows a graph of the amount of online players and the average uptime I could see mud admins getting enthusiastic about supporting it.
02 Mar, 2009, Scandum wrote in the 59th comment:
Votes: 0
Would a "MSSP" value be worth adding? This way MUDs could remove themselves from MSSP crawler lists by setting it to "0".
02 Mar, 2009, elanthis wrote in the 60th comment:
Votes: 0
David Haley said:
Out of curiosity, who all here except for Scandum thinks that the telnet options are the way to go? Just trying to get a feel for the consensus – if I'm the only one who thinks they're a bad idea, …


I don't think it's bad from a protocol design perspective. I believe it would have more uptake in clients if it were not TELNET-based, but if the target audience that Scandum cares about the most is crawlers, I think TELNET is fine. I have very real experience with trying to get ZMP implemented in clients, which uses TELNET the exact same way MSSP does… and most clients suck balls and require a complete rewrite of their protocol handlers to add ZMP. So do almost all servers (which admittedly, MSSP doesn't have to worry about, because it only sends the big chunks of data from the server, not to it). Given that use in regular clients isn't really the target audience, here, though, probably not worth being too worried about it. So long as all the crawlers are being written by smart people, it should be fine.

If we want to start talking about _ideal_ protocols, we should start from scratch and dump TELNET altogether and replace it with a message-oriented protocol designed specifically for data-rich text gaming. Idealism and reality don't tend to see eye to eye all too often, though. :)

The only huge major goof that will make MSSP suck I see is the use-last-value-on-omit semantics, which Scandum appears to just be ignoring the arguments against… at least, he hasn't responded to my detailed reasoning against it nor has he updated the spec. I have a feeling that all crawlers will just forgot omitted values anyway, but it would be ideal if the spec just required sane behavior to begin with.

I think Scandum's intent with that whole previous-value thing might've been solely for the sake of regular MUD clients that want periodic status updates. If you want that behavior without ****ing up MSSP for crawlers, I would suggest changing the spec to state that when a value is omitted, a client should keep the _previously specified value from the same connection, in any_. Then MUDs can remove variables at their leisure with no fear of crawlers retaining the removed variable's value indefinitely.
40.0/154