Homegrown Dedicated Server: DedCon 1.6.0_svn1038
Posted: Tue May 29, 2007 12:37 am
I though it would be time for some serious code hacking, so I'm working on one It's nowhere near usable yet, but I managed to connect to it with two clients, start a game, and place some units:
I don't know why the wrong territory is highlighted here. I probably made too many assumptions at one point or the other in the protocol. It's likely I need to flip one of those "this is always 1" numbers up to 2.
The nice thing about Defcon's network protocol is that I don't have to have the least clue about how the game commands work. If I'm happy to let all commands through unchecked, the server only has to record the client commands in a big queue and redistribute them to all clients in the proper order. The server is only responsible for the connections, the correct "beat" of ten ticks per second, for managing who can play, and for sending the active game settings to the clients. The rest is handled purely by the clients. Quite convenient for me. Connection management works, player management works half (the important half: adding players), the beat is currently too slow. Settings are a bit awkward on the network level; I'm planning to let the dedicated server fetch and store settings directly in the right format for the clients from the full game. Also missing is the communication with the metaserver and answering to score queries. They will never be fully functional because the server doesn't know about the scores, but at least, it will know who is playing. And I don't know at all how reconnection after you drop is supposed to work. So, don't ask when it will be done
What you see in the screenshot is also the biggest problem (and proof that I'm not just making stuff up) that I won't be able to get away, and that's why I'm already posting this, to get some early feedback. As you see, both players are in the game as demo players. That is because I used connections from a client with only a demo key when I analyzed the network protocol, so far, the actual player keys are completely ignored. Had I used a client with a full key, both players here would be full players. Not that it matters much, both are able to play. Whatever I will do about it, a reasonably skilled hacker will be able to remove it and play without demo restrictions. The same probably is true for the main Defcon program, but the dedicated server will be a lot smaller and the right places to modify will be much easier to find. Although I'm an Open Source guy, I won't be able to release the source for this thing.
Any version I distribute or run publicly will of course to some proper key checks. If I can't manage to decipher the metaserver key validity query messages (unlikely), I'll at least check for demo keys. But still, there is the risk that someone modifies the server in an evil way.
So, question, basically going out to the IV staff: Shall I stop right here before potentially easy to crack software gets set free? Shall I continue and at least run some of those servers myself? Or continue and release a binary? Would the benefits of having a dedicated server outweight the risk? The benefit would be lots of reliable servers that don't shut down until the last player quits, thus happy players and more customers by word of mouth. The risk would be a cracked dedicated server without demo restrictions. Making the binary only available for Linux would minimize the impact of that risk, I guess, without destroying the benefits too much.
Oh, and any good ideas for a name? I was thinking about SDI, Inofficial Dedicated Server (backwards), but you probably have better ideas.
Edit: the test releases can be fetched here: http://dedcon.simamo.de/
I don't know why the wrong territory is highlighted here. I probably made too many assumptions at one point or the other in the protocol. It's likely I need to flip one of those "this is always 1" numbers up to 2.
The nice thing about Defcon's network protocol is that I don't have to have the least clue about how the game commands work. If I'm happy to let all commands through unchecked, the server only has to record the client commands in a big queue and redistribute them to all clients in the proper order. The server is only responsible for the connections, the correct "beat" of ten ticks per second, for managing who can play, and for sending the active game settings to the clients. The rest is handled purely by the clients. Quite convenient for me. Connection management works, player management works half (the important half: adding players), the beat is currently too slow. Settings are a bit awkward on the network level; I'm planning to let the dedicated server fetch and store settings directly in the right format for the clients from the full game. Also missing is the communication with the metaserver and answering to score queries. They will never be fully functional because the server doesn't know about the scores, but at least, it will know who is playing. And I don't know at all how reconnection after you drop is supposed to work. So, don't ask when it will be done
What you see in the screenshot is also the biggest problem (and proof that I'm not just making stuff up) that I won't be able to get away, and that's why I'm already posting this, to get some early feedback. As you see, both players are in the game as demo players. That is because I used connections from a client with only a demo key when I analyzed the network protocol, so far, the actual player keys are completely ignored. Had I used a client with a full key, both players here would be full players. Not that it matters much, both are able to play. Whatever I will do about it, a reasonably skilled hacker will be able to remove it and play without demo restrictions. The same probably is true for the main Defcon program, but the dedicated server will be a lot smaller and the right places to modify will be much easier to find. Although I'm an Open Source guy, I won't be able to release the source for this thing.
Any version I distribute or run publicly will of course to some proper key checks. If I can't manage to decipher the metaserver key validity query messages (unlikely), I'll at least check for demo keys. But still, there is the risk that someone modifies the server in an evil way.
So, question, basically going out to the IV staff: Shall I stop right here before potentially easy to crack software gets set free? Shall I continue and at least run some of those servers myself? Or continue and release a binary? Would the benefits of having a dedicated server outweight the risk? The benefit would be lots of reliable servers that don't shut down until the last player quits, thus happy players and more customers by word of mouth. The risk would be a cracked dedicated server without demo restrictions. Making the binary only available for Linux would minimize the impact of that risk, I guess, without destroying the benefits too much.
Oh, and any good ideas for a name? I was thinking about SDI, Inofficial Dedicated Server (backwards), but you probably have better ideas.
Edit: the test releases can be fetched here: http://dedcon.simamo.de/