Right. So what's the required feature set?
Assumptions (please correct if any are wrong!):
* UQM's netplay uses a peer-to-peer model with two peers, rather than a client-server model. Thus player A needs to know B's IP and port, and B needs to know player A's IP and port.
* Moreover, currently A needs to be waiting for B to connect, and B needs to be waiting for A to connect. (is this correct?)
** This is kinda strange. A suggestion is to have A wait for a connection, then when B connects, we're done. A and B talk via the same port, at this point they know each other's IP address. If for some reason A needs to know B's port, it can be the first item sent. This means only A needs to have it's port open for incoming connections: usually firewalls can talk freely once an outbound connection has been made. (is this correct?)
* Also there's currently a bit of quirkiness in that you have to determine who is the top player and who is the bottom player (is this correct?). I recommend that in the future this gets phased out in some way. Since it's peer-to-peer though, there has to be some way to distinguish between player slots. My first instinct is for one side to just force the issue:
* There is currently no way to host a game server where you are not playing but others can join (ie a "dedicated server" so two other players can play; is this correct?).
* I'm also assuming here that even though you must currently specify all these details on the command line, in the future it will be possible to change these parameters at run-time, and they will change many times in one program run to play complete games on different servers.
* An integrated solution for finding games online would be cleaner than using some outside tool to launch the game via commandline parameters. For example, GameSpy had such a tool. Writing (or using) an outside tool could work as an intermediate measure. From my experience, temporary solutions end up being permanent more often than not. Google "lazy as a virture."

* This solution requires the creation of master server software. This also requires a dedicated server box set up someplace. If money's an issue, I recommend a "Slug" running on someone's dedicated home, business or school network and using a free dns service. Or paying for an actual DNS entry.

* This solution should not require any other external software or service. As in, you don't need a seperate ping daemon / web server / etc running.
Required:
* (REQ 1000) Players can start a game server to host a game with themselves as a player.
** Starting such a game server advertises its availabilty to a master server.
** By virtue of sending this message the sender's external IP address is revealed
** The sender may also have to specify which port to use.
** This request also specifies which player positions are in use and which are available.
** For future use, "max players" might be better than available player positions.
** For future use, we might specify the "map", "gametype", existing players in the game (enumerated by their names). Console games typically have a "matchmaking service" whereby they don't show a list of servers in the UI; instead it picks a server that matches the player's chosen criteria. Here is where such clues are given.
** This master server may also return some info from the request.
*** For example, a generated unique public game server ID. This is useful for distinguishing between multiple servers behind the same network, using the same external IP and port. May also be used for updating the server's stats.
* (REQ 1001) Players can get a list of available game servers by querying the master server.
** Players can send in a request to the master server. For now, it doesn't look like there's much to specify in this outbound request. The master server doesn't really care about the player's IP, port, player position etc.
** Should Filters be done on the requester's end or the master server's end? So if the player specified in a UI someplace that they do not want to hear about full servers or something, do we make that part of this outbound request (at the expense of the master server's CPU time) or do we do that on the
** The return from this request is a list of servers. For each, we have:
*** Public IP and port
*** Number of players currently in the game
*** Number of available slots, and for each, their "position." This position should be phased out at some point.
** Curiously, the server's ping is *not* returned here. The master server has no idea about the ping time between anything; instead it's up to the player's software to ping the game servers.
* (REQ 1002) Game servers can update their stats on the master server.
** Same as REQ 1000. The main reason this exists is to prevent the server from reporting multiple instances of the same server (by using that unique server ID).
* (REQ 1003) Ping from one game server to another.
** Useful for weeding out bad game candidates. Presumably the UI can sort a game list by ascending ping time.
** This should be done by UQM code.
* (REQ 1004) UI update for finding online games.
** Think Quake 3's browser list. You can sort and filter results.
* (REQ 1005) UI update for creating / hosting an online game.
** Presently there's not much to adjust: your port is about it.
** For future expansion, this should be made a seperate UI page. There may be things like choosing maps, gametypes, specifying max players, etc.
Sounds Great! Now what technology is appropriate here?
Raknet. This is a network library, which includes among other features, a fairly quick and easy way of implementing a master server and client code.
This lib used to be available as GPL code; now it's an "Attribution-NonCommercial 2.5" creative commons license. This is GPL-compatible, but it adds the additional restriction that the resulting binaries must be non-commercial. Now it might just be possible to work something out with the author such that we pay for the commercial license, but we still end up with a GPL-compatible license... I dunno.. this kinda licensing makes my head spin. Or maybe it was the Sambuka.

Anyhow: great tech, but licensing will have to get sorted out.
Use SOAP calls. Simply put all the stuff talked about above into neat XSD-formatted SOAP requests, use some GPL-compatible lib to generate your code from the XSDs, and Bob's your uncle. Or Toy.
This is actually a fairly clean solution. It means adding a build target to generate this code, plus adding the XML parser libs etc, but once that's out of the way this is really cheap maintenance, even if we add crazy features like easy matchmaking services like XBox etc have. I was actually going to try doing this using a Java client front-end that just calls the commandline + a Java server, just because it happens to be familiar.
Note that we are *not* going to hand-roll our own XML parsers etc. *sigh* many a programmer has gotten overzealous and coded such solutions, only to pull out their hair when the spec changes...
Hand-roll our own code. Nope, not a good idea. Aside from the idea of which slots are available and the fact that the two players must know each other's IP addresses, this is definitely not a unique problem. Someone's bound to have code for this, and this is what open source is for!

Go find someone else's code that already does something similar and use it. Someone want to spend a few minutes doing a google "site:sourceforge.net ..." so see if there's something already out there?

Ok, so are those assumptions even slightly right? Is this the required feature set?