I disagree. There is no *speed* difference between TCP and UDP. The only difference is that, with TCP, if packets are dropped, you have to wait for a re-send before other, received, packets can be delivered, because TCP guarantees in-order delivery.
UDP should be used when low receive latency is more important than ordering, which is the case for internet telephony, and *some* kinds of games.
From my personal tests; UDP can be a tiny bit faster, but as I said, it's not worth reworking if you favour your current implementation (for simplicity/whatever). Of course, after reading through the first bit of his post again, I've noticed that he's actually setting NoDelay to true, disabling Nagle, which really helps a great deal (personally; I have it disabled system-wide).
4) Data is only sent when someone actually DOES something
Ehh... This is generally frowned upon
Generally frowned upon by whom, and why? Not sending data you don't have to send is generally approved by all network programmers I know.
I said this because I figured the game would follow typical MMORPG mechanics, was I incorrect in doing so? Is he
not designing an MMORPG?
You see; in an MMORPG at least one of the things on the list below would be considered typical (but who am I to make such a statement?):
1) Health, mana, etc-regeneration: sending a small packet when this is meant to occur is a good idea, especially with varying rates of regeneration. This is not necessary, but otherwise the client and server will have to constantly keep track of the player's health on an elapsed-time basis, even while idling, and who's to say the client isn't modifying that value? Or skipping ahead/behind?
[1]2) General client keep-alive, so that the server always knows whether or not to include players in the area-list after they disconnect. The alternative would be to check that every sent packet is received, but there would be an issue with that, considering the fact that "Data is only sent when someone actually DOES something." Consider the following scenario:
___1. Bob logs in to the game and goes to "Map 1."
___2. John logs in and goes to "Map 1," as well.
___3. Bob's internet goes out, so he can't tell the server: "HEY! I've just left the game! Don't show me on the map!!!"
___4. John will endlessly see Bob on the map, as he has not done anything
[2] and therefore; will not be updated.
___(5.) John tries to talk to Bob, but he doesn't reply (since he is
NOT online) D: John now hates Bob for ignoring him D:
3) Environments that the players can interact with are pretty much a given in MMORPGs. Will the monsters just drop movement if people idle in a certain area, because "Data is only sent when someone actually DOES something." According to what you are saying, I could do the following:
___1. Go to some sort of unpopulated dungeon-map.
___2. Fight my way through it, all the way up until the big-boss/whatever.
___3. I then look at my clock; "Oh, it's lunch-time!" I say.
___4. So I just stop pressing any keys, go totally idle, and leave for lunch.
___5. I come back an hour later, start moving (which in turn, re-activates the boss, because I would be doing something) and kill that boss.
The system which you seem to be proposing can be compared to implementing a pause-button in an online-game! Such a "freeze-area-until-interaction" system would only be ideal for entirely turn-based environments.
4) Skills with cool-downs are commonly implemented to prevent users from spamming-skills and reaping the benefits from doing so. There are multiple ways of implementing such a cool-down system:
___1. You could use an entirely client-sided cool-down system, which enables skills based on the amount of time elapsed since last using it. This is a
horrible idea and would make any game susceptible to hackers, through either placing a JMP to the skill-reset address directly over the cool-down procedure, or hooking GetTickCount/timeGetTime/QueryPerformaceCounter and returning invalid time-values which would accelerate (either positive or negatively) the speed of anything based on the client-computer's time.
___2. You could have fully server-sided cool-downs which are checked immediately as the skill is attempted, the server would then report the skill's availability back to the client. This method is
brilliant for preventing hackers (though, not anymore than method 3), but it lacks compensation for lag which might be experienced by players with poor connections, as skill usage would require a send, then recv, and then, optionally; another sent-packet.
___3. The server could send a small packet to the client anytime a certain skill became available after cool-down. Of course the client would also be measuring the cool-down based on the client-computer-time. allowing for lag-compensation and smooth gameplay. With the client also measuring and executing the skill, the server could do a check to ensure it has executed properly, if not a roll-back packet should be sent, and the player's position/status/etc. would be rolled-back to the proper time. This method only requires a single packet to be sent (Client --> Server) upon using a skill, though your current server-design (freeze-area-until-input), would rule this method out, because cool-downs should still be processed even while the player is idle.
Why do you multiply by 500 twice?
Because, as he said, he's broadcasting messages from 500 players, to 500 players. This is the basic n-squared growth of traffic that's the core of all MMO systems.
Haha, I apparently misread the original post, and thought that only 20 of the 500 players were broadcasting 12-byte chat messages, when, it is actually a rather different case.
I do believe that if you want to avoid hackers; it would be best to do a simple XOR over your packets (in case you didn't know; XOR = fast-as-hell), with a certain pattern determined at log-in/whenever.
First, the speed of XOR scrambling versus a real cypher doesn't matter much. The available bandwidth on a computer limits how many bytes need to be encrypted per second, which in turn means that the overhead of the encryption is very small compared to available CPU power.
Second, scrambling with XOR instead of using a real cypher is a really bad idea. If your data needs encryption, you should encrypt it, not just cover it in the thinnest of layers of paint.
Third, you cannot really protect against hackers by encrypting your data anyway, because the hacker has full control of the client machine.
You seem to believe I am not well-versed on the subject. I did not claim that XORing through the packets would provide some sort of magical, and unbreakable cypher-scheme. It will, however, make the packets appear meaningless to those peering in with packet-loggers/etc, especially if used with a random key. In order to prevent disassembly of the client-executable, I would use Themida, or another form of protection, and then top it with something similar to GameGuard/HackShield (which pretty much rule out the use of injectable packet-editors).
The main reason that I mentioned XORing, is because doing so is considerably fast (making it ideal for operating on a server), almost 116 times faster than a simple Rot13, and about 126 times faster than AES/Rijndael (using ten cycles and a 128-bit key)
[3].
Side-notes:1. Generally; I wouldn't even go with this, as with a great deal of players it can become annoying having to iterate through a huge array of players, and send an update-health/etc-packet every x seconds. I would simply program the client to update HP/MP/Whatever according to time-passed on the client computer. The server would always hold the true values, which should be synchronized with the clients, therefore allowing it to make accurate calculation for skill-requirements, death, etc.
2. The character representing Bob literally will not be updated as a forced disconnection can be unpredictable, meaning that no logout-packet could possibly be sent. Since the server doesn't know that Bob is offline, it will assume that he is idle and nothing will happen with his character. Of course, the scenario proposed might not be accurate, since I do not know how your server handles errors, and it might just as well notice that Bob is offline due to him not receiving the packet which notifies his client of John appearing/speaking in his area. Regardless; if John weren't there to make Bob error-out (if such a thing were to occur as a result of John's actions) and be removed from the player-list, Bob would endlessly remain online, this might present a problem if he were to try and log-in after restoring his connection.
3. All tests were performed on a string of 64-bytes in length, with the elapsed-time being calculated using QueryPerformanceCounter. Using XOR-based encryption, I was able to encrypt the string 1,000,000 times in 13 milliseconds. It should be noted that the reason for me using ten cycles and a 128-bit key with AES, is because those are the minimum requirements for it to be classified as such.
0
