It's the test port, but normally it's only running for a few minutes at a time while I'm testing something, and I don't invite other people, so I hadn't realised there was a firewall issue.

Try port 3000, I've copied it across to the operational mud. Note that "players" is currently just returning the number of connections, regardless of whether or not they're logged in. Presumably it should actually return the number of connections which also have a character (so no link-dead people, and no connections sitting at the login screen). You wanted it to ignore duplicates from the same IP addresses as well, right?

;;lsiotne guyts wwhgerteveyrtufgai

I suggested tabs (waaaay back, several threads ago), mainly because they aren't likely to occur in any of the normal data MSSP expects one to supply. If you start sending banners or big blocks of text, I think it's safe to make tabs illegal inside keys or values. If someone really wants such a thing, they can always use \x09 or similar and expect the other end to decode it.

This makes things very easy to parse…. strip off the leading whitespace and MSSP-REPLY-START, and the trailing MSSP-REPLY-END and whitespace. Use split or explode on "\r\n" to get an array of all rows, and then split/explode on "\t" for key,value,value… sets on each one.

As for the order of checking…. that's simple.

If the mud supports MSSP via telnet options, the crawler will handle that during connection and it's done.
If no such negotiation happens, it can then try loggin into the MSSP-REQUEST account.
If it gets the data, we're done.
If that login fails (IE: no MSSP-REPLY-START is sent), the mud doesn't support either, and so we're done.

I don't think I said anything new here, does that sound like a summary of where the thread stands at present?

Well the only modification I'd make to your summary is that there seemed to be some support for having an option checkbox set when the admin registered the game for crawling so that the crawlers won't arbitrarily be trying to send MSSP-REQUEST unless the listing says they support plain text. Unless you're proposing the crawler show up, try one, then the other, and if both fail never come back?

Sounds reasonable, although I don't think it needs to never come back. The reason for having the checkbox is to avoid annoying the muds that don't support MSSP - but if they don't - and they've explicitly clicked the checkbox - then the crawler's visits would encourage them to either add support, or uncheck the option.

Do we know which listing site/s are interested in using MSSP? I imagine it would seriously mess up TMC's auditing approach, but it could have a strong appeal for other listings.

Kiasyn is working on a crawler for us here. I don't know yet if he's planning to put the option checkbox in or not, but I think it should be there one way or the other so that folks who don't support MSSP don't keep getting prodded by crawlers that do.

A checkbox at the crawler's end to disable text mode would be polite, but that's more a usage issue rather than part of the protocol's design. At present, crawlers connect to the muds and (perhaps) read up to the login prompt before disconnecting. I don't see a single attempt to login as MSSP-REQUEST to be too onerous, unless you're hitting the poor servers more than a couple times a day.

I would probably suggest that such a checkbox just be "Allow MSSP?", since those who support the telopt version will never see the text request (since the telnet one would already be fulfilled by the time the login prompt shows up).

Looks to be working. I noticed you didn't add http:// before the website address which messes up your link on my crawler page. The Kingdoms of Ahln Mud has the same problem.


Yes, duplicate IPs ought to be ignored on Muds allowing multi-playing. It's a bit tedious to add though, I wonder if there's an easy algorithm to loop through a list of connections once and return the number of unique IPs.

Not sure if I should add that the connections must also be logged in? Right now I assume some muds count the crawler as an actual player.

My crawler currently spams MSSP-REQUEST if it doesn't get IAC WILL MSSP within a second of making the connection. I agree that this should be left to the crawler, there are several ways to go about this, from a check-box to checking non mssp muds for plaintext support once a month.

Edit: Both TMS and TMC have shown interest, I didn't bother contacting other mud lists.

I've changed it for the next update, but are you sure you want people adding that? When editing my MudBytes listing it explicitly states "Do not include http://", so that means it'll need to be stripped anyway.

Should I also use "telnet://" for the hostname, to be consistent?


I already calculate that for the "users" command (it sorts players by IP address, making it easier to spot alts at a glance), so I can reuse that code. I'm just concerned that people could use it to work out alts, but I guess that's not such a big deal.

To be honest I can see a lot of muds refusing to ignore duplicate IP addresses, and it's not the sort of thing that can be proven (even if you're able to prove that people are multiplaying, the mud owner could just claim they were using a proxy).


Yeah it probably shouldn't count that. I'd suggest only counting connections that also have a character.

Most listing sites have an option for the average number of players. Is the idea that the crawler will calculate this value by frequently checking the mud?

And note that in many countries ISPs have whole blocks of users NATed and showing as single IP.

Uh? You mean like any algorithm used to count unique occurrences?

Anyhow we've been over this before ample times, it's very dangerous to assume that one IP == one person, even if multiplaying is allowed. People will just have to use discretion when they see lots of players on a MUD that allows multiplaying, or the crawler could put up an asterisk explaining that multiplaying is allowed.

I hadn't thought about that yet. I know some sites use https instead of http. Some more opinions would be helpful.

Edit: The protocol currently states to list the url, which as far as I know implies needing to use http://


Definitely not, that would only complicate things on the crawler's end.


That's one of the things MSSP would be ideal for. I think Kiasyn mentioned he wanted to do 3 hourly updates. I was inspired by mudstats.com when I initially brought up MSSP.

Not sure if the Mac address could be retrieved, that'd work better.

I don't think it'll be a huge issue, but there are Muds where people play with 5 characters at a time, and that could inflate the player count quite a bit.

Mac addressing is specific to the local network segment.
From the perspective of your mud server, all internet traffic comes from the MAC of the nearest network device of proper layer (2? 3? i never remember) on the path (router/switch/gateway).

Yes, it would, but I don't think there's anything reasonable we could do. Counting unique IP addresses could also deflate the player count when several people are connecting from one school, for example, which very well could be NAT'ed.

Basically this is a number that is subject to human discretion anyhow, so we shouldn't try to regulate it. If a MUD allows mplay, just make a note of that next to the player count.

And yes, it's impossible to get the MAC address of the originating sender. The MAC address is used at the ethernet level, not TCP/IP. On my own home network, I can't see the MAC address of some of my own computers on my local network if there's a router in between.

MAC addresses can't be retrieved, as already noted. However, MAC addresses aren't really unique anyway. They are just very likely to be unique in any single network segment. At my last job where we ordered large batches of network cards we'd quite often get several that had identical MAC addresses to cards we already had on the network… which was always a bitch to figure out. Once identified though we just made sure that those cards went to different buildings.

The reason for that happening is pretty simple. Despite being 48-bits (more available addresses than atoms in the moon), relatively little of that space is used for individual card identification. A good chunk goes to manufacturer identification, and then manufacturers tend to put the card model number in there as well, and possibly a partial manufacturing timestamp. The remaining bits are cycled for several reasons, not least of which is that actually tracking used MAC addresses when the same hardware is manufactured in numerous different foundries is just damn hard. End results is that manufacturers often reuse MAC addresses, especially on cheaper cards (e.g., anything Linksys, which are often rebranded Realtek parts).

In general, I agree with David. Just note that the MUD allows multi-play and lets crawlers or other consumers make what they will of that information. If you want to help them get the most accurate info, the MUD could communicate a full list of active players with (partially obscured) IP addresses, so the crawlers can figure out a graph of their own. A MUD that explicitly allows multi-play might consider using a simple account system in addition to player profiles so that it can identify unique human players in addition to number of player characters logged on. Perhaps MSSP should have a way of identifying that info as well; dunno if that's overkill or not.

TMS has the same issue, 1 vote per 12 hours per IP, never heard anyone complain about that.

This is not so much about doing it right, but allowing a fair comparison between muds. For that sake it's perhaps best to drop the multi-play thing, and simply request the total number of logged in players from unique IPs. That should provide a clear and strict guideline, and if a mudlisting so desires, it can ban cheating muds like TMS does.

If you can't "do it right", you can't "do it fair". Your suggestion is going to punish MUDs that have several players connecting from NAT'ed networks.

The notion that one IP == one person is completely wrong, so it doesn't make any sense to base a supposedly "objective" comparison on it. This is a subjective measure – don't decide for people how to look at the data just because you look at it in your own way.

The best compromise would be to provide the number of sessions and the number of unique IPs, but as somebody mentioned, that could be used as a tool to find alts – whether or not that is a problem is an interesting question.

In any case, whether or not multiplaying is allowed is a very important data point regardless of this number of players issue.

Just out of curiosity: how much discussion is there between you, or anyone, with TMS/TMC in regards to what data MUDs intend to provide? Like I know you pulled most of the variable set from what TMC uses, but is there anything they don't care to see or would want to add that we as owners could provide easily? I'm all for making my own listings more robust and easier to update via this. Issues like this, about player count, would be useful to have listing site input on in regards to what numbers they want to see. I don't frequent TMS but I know TMC allows you to specify average # of players, and may(?) impose some guidelines as to what a "player" is.

edit: clarification