I think it would be nice if the DMP Client had the ability to read off the server tables (The PHP? one on http://godarklight.info.tm/dmp-serverlist/) into the in-game server list so users don't have to copy each one or cherry pick servers into their list.

Maybe this could be implemented as a tool, which replaces the blahblahblah part of servers.xml with extrapolated data from the public server list.

Anyway, just a suggestion/enhancement.

One better way to do it is Valve style.
Having the server send a heartbeat to the master server, then displaying the alive servers in a browser window.

Okay, so after a while, I realized that this was a horrible implementation for something this small.

A simpler system is as follows:

1. Server sends the IP address and port of the server to the master server. Some sort of limit should be imposed to prevent spam.
2. Master server becomes "subscribed" to the server, making sure that the server actually exists.
3. Every five minutes or so, the master server will poll and ping every server in the subscription list. Each server provides its own name and description when "pinged". Servers pinged successfully will appear in the server list.
4. If 10 polls pass and a server is not pinged successfully, then the master server unsubscribes from that server.
5. Self-service mode: the master provides the subscription list, and DMP clients must individually ping servers in the subscription list themselves. However, servers must re-subscribe to the master server every few hours or so.

Yes, a "heartbeat" mechanism would work pretty well.

Basically, the heartbeat system would work like this:

1. Server asks for a new "key" from master server.
2. Master server provides a public/private key pair.
3. Server sends a "new server" request to the master server, including the private key, server name, IP address, and port via JSON. Additional data could include server description, owner name, and owner private key (only if owner information is protected). New server requests can only be made when the server has been unpublished for more than an hour.
4. Master server sends 200 OK or 400 Bad Request or 418 or any other HTTP status code depending on the message. If OK, then master server will send back info including the server's public key, heartbeat length (default 4 hours), server data if there were any changes made to the server information, and whether or not the server is currently published. The server is considered published until the 4 hours are up.
5. A server can send a "modify server info" request with the private key and the title and/or description of the server if either need to be changed while the server is published. The title can only be changed once per 12 hours, though.
6. A server can send a heartbeat to renew the "lease" simply by sending the private key and "heartbeat": true to the master server. The master server will then include the new heartbeat length/lease time in the response.
7. Key pairs are destroyed after two weeks of inactivity, and key pairs may only be generated once every 24 hours unless a special "server fleet" key (which would be created upon request by the master server's operator) or owner private key with "server fleet" privileges is sent along with the new key request.

Maybe my system is a bit bloated/sophisticated, but it will come in handy for when DMP becomes very popular.

Public queries would be very simple; you would just append ?format=json to the master server list page, and you would get every server in the list with its public key, number of players online, description, owner information, website link, and address. It would be like magic for the clients.

I've decided against this if it's going to use a master server, I don't want DMP contacting anything other than the server you are connecting to, it also makes following the addon posting rules slightly easier ;).

Also, My server definitely wouldn't be up to the task, and this thing would need to gracefully fail.

An external program that could start KSP directly into a DMP session on the other hand would probably be the way to go, especially as it's possible to sort out GameData before KSP starts.