Personally I wouldn't bother encrypting your game data packets - certainly don't use PK encryption to encrypt data (use symmetric encryption instead and use PK to exchange symmetric session keys).

There is no real point in encrypting the data - the end user can make unauthorised modifications to the data anyway before it's encrypted (by attaching a debugger etc), so the server has to be built not to trust anything from the client anyway.

As far as someone intercepting the game packets and using it to cheat... now that's just speculation, I don't believe it's going to happen in practice.

For using peer-to-peer for your game- just don't do it (see the forum FAQ).

Running DNS is a piece of piss compared to a game server, so you should not have a problem doing that. Existing DNS servers have hooks that enable you to programmatically dynamically update them if you want - just look some of these up.

Mark

Quote:Personally I wouldn't bother encrypting your game data packets

I see your point that encryptions can be bypassed anyway, but I don't think that alone is enough to say "lets not bother encrypting."

A server should authenticate everything, that is the ideal situation. Unfortunately, there's always something that a programmer will fail to oversee, and that is demonstrated even now, as people are constantly finding new exploits in games even 3 or more years old. (I don't think there has been on online game to date where no exploits are found. No programmer is perfect.)

Hooking an application to intercept its packets before encryption isn't the most difficult job to do. I imagine you, or most of this forum would be able to manage to do so. However, the majority of your online gamers will be teenagers or kids that will have absolutely no chance of doing so.
All of your online players though, have the ability to open up a pre made program like Ethereal/WPEPro, and convert hex to decimal (they don't even need to know how, they can get something to convert it for them).

My point is, if you are sending raw un-encrypted data, it is open for 100% of your players to modify, spam packets or exploit bugs if they wanted. If you had the ideal server, none of that would matter, but really, no server is ideal.
Even the biggest multi-million dollar projects like WoW have bunches of exploits from packet modifications, found by just a small percentage of its players who know how to decrypt data. Imagine all of its players could read data as raw packets, then estimate the number of people who'd be cheating, or attempting at least. You'd have a fair few more exploits anyway.

Simply put, if you encrypt your packets (the method doesn't matter at all), you remove the ability for the majority of players to view or edit them. There will always be comp savvy players who can bypass it, but they are a minority. The fewer who can, the fewer that will. It is worth putting some encryption in there.

Your DNS idea is a good one, but it's also not a good one. It's very clever to try to take some of the load off of your login server with dynamic IP addresses. However, you're right to worry about caching. DNS can be extremely finicky, and sometimes things will work great and instantly for some people when you make a DNS change, and sometimes it will take days and days for some parts of the Internet to catch on.

If you're set on using DNS, I'd recommend not using the operating system's DNS capabilities directly, and instead contact your authoritative DNS server yourself. Then you could control the caching with total reliability. Downside is that you'd have to write or find a DNS client.

I'm not an expert on dynamic DNS, though, so I'd check around to make sure there's not a magic solution to mark DNS entries as dynamic or something.