Reversing GGP Client/Server Protocol: Match Request Issues

One of the main reasons that Tiltyard exists is so developers can get everything working (including router configurations) at their leisure, before they're involved in a time-sensitive environment like a competition.

I agree this is a source of difficulty though. I'll look into adding better documentation and error messages to help developers whose players aren't showing up on Tiltyard due to not being accessible over the network.

I just did a quick experiment to see if I could write an intermediary server to solve this problem. The idea is that the server would sit somewhere easily accessible with a fixed IP address and would accept incoming client connections from both the players and server. Players would connect into the server (with some username/password scheme) and be informed of their assigned port number; the server would then connect to that port number, using the existing protocol. The intermediary would pass messages between the server and client, with the client using long polling to wait for incoming messages. (The API is designed to avoid skipped messages due to untimely dropped connections.)

Actually, the only connection that needs to be held open for a long time is the one between the server and the intermediary server (waiting for a response), suggesting this might be a working approach for the server to implement.

Currently I'm blocked on the fact that Dropwizard (which I'm using as a learning exercise) doesn't expect applications to use more than one port. An alternative would be to host players at different addresses on the server (something like playerhost.ggp.org/player?name=Alloy). Unfortunately, both the GGP-Base and Dresden servers expect players to be at the "/" location, i.e. there can't be anything after the "/" in the URL. I might be able to get this working with something that uses raw Socket or URL connections instead of a server framework, but for now I thought I'd share the approach I'm using for the client-side communication:

1) The client sends a register command to the server with a username and password. This is accepted unless the username has been used before with a different password.
Response (if no error): <address the player is available at, next message ID>
2) The client sends a receive command to the server with the next message ID it's expecting. This is a "long polling" request, i.e. the server tries to wait until an answer is available before responding. However, it can also time out at any time with an error; in this case, the client simply repeats the request with the same message ID. After a successful request, the client can immediately start polling for the next message.
Response (if no error): <current message ID (for sanity checking), next message ID, message contents>
3) The client sends a respond command when it is ready to send a response to a message.
Response (if no error): <current message ID, next message ID> (both for sanity checking)

Message IDs are base 64-encoded strings generated by a secure random number generator, i.e. they won't collide (with high probability) and would be sufficiently long that they're basically impossible to guess. The server would store messages for some reasonable length of time.

Note that long polling is more or less necessary when reversing the connection to keep latency low, which is essential because of how turn deadlines are communicated.

I wouldn't expect this design to pose any real problems for a distributed player; it would have an entry point for messages (or several), some mechanisms for computing responses, and then an exit point for sending a response (which includes a way of specifying which message it's for, so it wouldn't hurt if the response wound up getting sent twice). The remaining robustness problems have to do with the inability to replace a previously sent move, which is a higher-level limitation of the current protocol.