In a MMORPG, how many players are reasonable on one server? Using UDP sockets. I'm currently designed my game to hold 100 players, but I see game servers that hold 800+. How do they do this?

Your greatest problem:

UDP has no flow control. In fact, as far as my personal experience goes, I have never encountered a UDP based MMORPG, and it is most likely for this reason among others (another being that UDP is connectionless, meaning the game server must keep track of connections manually and take additional CPU power to prevent UDP spoofing attacks).

Quote:Original post by Michalson
Your greatest problem:

UDP has no flow control. In fact, as far as my personal experience goes, I have never encountered a UDP based MMORPG, and it is most likely for this reason among others (another being that UDP is connectionless, meaning the game server must keep track of connections manually and take additional CPU power to prevent UDP spoofing attacks).

Please go on, I want to hear it all! [smile]

I went googling to refresh my memory on the subject, and found this thread, an oldie but goodie.

Anyway, in the world of MMOs, I think most stick to TCP, but DAoC creates both a TCP and UDP connection. I imagine that they only use UDP for unsecure and unimportant messages (like display related events, such as "this guy is swinging his weapon now, draw that animation"), which are OK to get dropped, and not a big deal if someone tries to spoof them. All the important stuff goes through TCP.

Quote:Original post by pinacolada
which are OK to get dropped, and not a big deal if someone tries to spoof them. All the important stuff goes through TCP.

Each UDP packet that gets sent to the server contains the account information of the sender, so its not likey someone is gonna spoof anything in my game.

There is no "Connections" on the server, yes, but why is that such a terrible unreliable thing? (I know someone is gonna say this, so I'm gonan clarify it now). My server checks that the username and password are correct from the packet, and than it deals with the packet.

Soo simple~

Also, lets not drift outta topic.

UDP and TCP are both reliable. Since reliability is relative to the task.

UDP will not fail to keep my server running just the way I want it to. Since the packets contain absolute information: lossed packets every now and than isn't a problem at all.

In addition, I don't know how I'd get TCP working in a Procedural-C application, since I can't allow 1 connection to slow down the rest.

Flow control (a feature of TCP) is a method determining when bandwidth has been saturated, at which point is stops sending packets to prevent a backup.

To begin with, lets take your UDP based server and assume some clients are connecting (for now we'll ignore the majority of data being sent by them, just the data the server is sending to them). Now obviously you've implimented some form of [semi-]reliable UDP (so if a UDP packet is not acknowledged as being recieved in a certain time frame, it is sent again). Your server is happily going along sending out updates to those clients (say, 8 packets/second, at 256 bytes per packet - 2KB/s). At a certain number of players however that 2KB/s (plus overhead) is going to be greater then your actual bandwidth (or there will be a spike in player activity, causing a bandwidth spike). With TCP, it would very quickly determine that bandwidth was saturated, and start holding back until data already queued was sent and recieved. With UDP however your server would just be blindly trying to send all the packets. You would start getting serious packet loss. Since (at least some) of the packets are meant to be reliable, the server would realize they had not been recieved, and start resending them - this would only make the problem worse, as more and more packets are being sent at once, all of them being lost, and thus causing the server to try and resend them. Even a short bandwidth spike could result in a chain reaction that effectively causes a denial of service.

Now up to this point we haven't even started on clients. The clients, at a certain point when packet loss starts to pickup (as covered at the beginning of our last paragraph) would start resending their own packets. The extra packets would jam up the line even more, causing more packet loss, and causing more players to begin resending. Pretty soon, despite the clients benevolent intent, they would be creating a powerful distributed DoS attack against your server.

Quote:Original post by Westeria
UDP and TCP are both reliable.

No.

UDP isn't just about a few lost packets.

UDP packets can arrive out of order (i.e. packet 2 before packet 1).

UDP packets can arrive multiple times (i.e. 3 packets are recieved, but 2 are duplicates).

UDP can spoof IPs and does not required a connection (making DoS, both to server and players, possible without additional CPU overhead, which can be used to help a DoS attack)

Quote:Original post by Michalson
Now obviously you've implimented some form of [semi-]reliable UDP (so if a UDP packet is not acknowledged as being recieved in a certain time frame, it is sent again). Your server is happily going along sending out updates to those clients (say, 8 packets/second, at 256 bytes per packet - 2KB/s).

I have developed no such [semi-]reliable UDP. There is no acknowledgment system in my server or client.

If you walk up to an object in my game, the data that makes up the object is getting resent to you everytime a game update packet is sent.

Stupid? Not when you hear the facts: Its impossible for their to be more than 240 objects on the screen, and its very very rare. With my new design, 90% of objects are 5 bytes.

1.17KB per player standing in an absurdly dense zone... not bad, not bad at all!

Especially when it saves hundreds of lines of unchartered net code.

rofl, would you believe my netcode is like 30 lines, and besides being vulnerable to DoS attacks, its completely secure (Nearly everyting is server-sided).

Edit: Before the flaming comes, I'll ackknowledge that sooner or later I'll have to change my netcode to a little more bandwidth conservative. But at the moment, its fine and dandy!