Max players on UDP?

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 [snip] 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.

Well, as you know which packets are still not acked, you can easily count how many packets are still not acked, and suspend or at least throttle the sending of new packets until either the acks arrive or the connection totally times out.

Implemented that in Zoidcom and works like a dream. You just have to know what you are up to when utilizing UDP and everything will be fine :)

Regards,
Joerg

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!

Quote:

Original post by Michalson 1 - UDP packets can arrive out of order (i.e. packet 2 before packet 1). 2 - UDP packets can arrive multiple times (i.e. 3 packets are recieved, but 2 are duplicates). 3 - 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)

1 - Yup, but why does this make it unreliable in general?
2 - Yup, but why does this make it unreliable in general?
3 - UDP can spoof IPs, but TCP cannot? I don't believe it.

Quote:

Original post by Westeria 3 - UDP can spoof IPs, but TCP cannot? I don't believe it.

UDP is connectionless, therefore no "handshaking" and no real connection. Packets are just sent with a from field and a to field.

== UDP ==
--Client Packet--
From: 192.168.0.1 To: 192.168.0.2
Packet: *blargh*

Rogue packets can be constructed with fake IPs in the from field and your server has to manually verify those to ensure they exist, otherwise it's vulnerable to spoofing attacks. Your server must send a packet to that IP and recieve an appropriate response packet to be sure it's not spoofed.

With TCP handshaking is part of the protocol.

== TCP ==
--Client Connection Request--
From: 192.168.0.1 To: 192.168.0.2
Packet: SYN

--Server Response--
From: 192.168.0.2 To: 192.168.0.1
Packet: SYN/ACK

--Client Response--
From: 192.168.0.1 To: 192.168.0.2
Packet: ACK

If the client spoofs the IP of the SYN packet it won't recieve the SYN/ACK packet and therefore won't be able to send a valid ACK packet. This makes spoofing _extremely_ difficult for TCP connections.

OIC.

Thanks RA!

Quote:

Original post by Westeria 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~

you send eveyr packet with a username/pass? isnt this expensive bandwith wise? also, whats stopping a person from just spoofing a packet with their own login name and password in it?

Quote:

Original post by graveyard filla you send eveyr packet with a username/pass? isnt this expensive bandwith wise? also, whats stopping a person from just spoofing a packet with their own login name and password in it?

~20bytes.

But erm, whats wrong with them spoofing a packet with their own login information? All they could do is tell their player to move in a certian direction or fire at a certian point releative to their characters position, I don't see the harm in that.

well, i just think that it's pointless. i DO see how its usefull for sending things like character selection screen, character deletion, log ins, character creation etc. we wouldn't want someone spoofing a packet and deleteing a character on someone's account.

however, i just don't see the point in doing it with movement or firing packets. i mean, the server should track who is sending us a packet in the first place, so we shouldn't even need to verify that this person is legitmately the person he says he is.

although, to be honest, i'm no expert here. i use rakknet which manages connections for me. raknet ID's a connected player through a ip and port combination, to guarentee all connections are unique. i don't know all the inner workings of raknet so i'm not sure if this initial connection information is spoof-able, but im leaning towards no. please correct me if i'm wrong so i could be aware of this security loop-hole =).

but, i guess my point is this: i'm more worried about clients who are legitmately logged in and own legitamte accounts spoofing packets. everything past the login stage is more important to me to not get spoofed since its in real time. they could spoof packets to make themselves move to a place they shouldnt, or attack someone they cant'. however, obviously the server should be server authoratative and handle this security. but, i said i worry about it, not that i think it will happen to me [smile].

PS, aren't these commercial MMORPG servers actually running on multiple physical machines? or do they really handle 1-2k players on a single box / connection? how fast do you think their up/downstream and overall PC specs are?

Nothing could possibly make more sense than implementing your own reliaable UDP protocol.

1) UDP can handle various firewall situations better.
2) You can customize how your bandwidth is used as far as packet garenteeing. When you use TCP, you hand control of these things over to its protocol, and network bandwidth is the single tightest bottleneck left in computing, much worse and more expensive for a user to upgrade than memory or video card or CPU speed.
3) Check out Clanlib networking or Torque net library, both use reliable udp protocols and are MUCH MUCH better for sending real time game information than tcp could ever be.

Quote:

Original post by Anonymous Poster There are *plenty* of MMOG's that use UDP (enough that I never bothered to memorize their names). Why the heck would you NOT use it? If you have the budget to write an MMOG, you probably have the budget to rewrite TCP using UDP and conveniently omit the "all packets arrive in-order" and "all dropped packets are retransmitted always, transparently".

Yup, I knew this. Didn't believe Michael~ either. UDP should even be more popular than TCP, since it's hella alot easier to conceptualize (Kinda reminds me of the C vs C++ theads). "Remember kids, the right tool for the right job!"

Quote:

Original post by Anonymous Poster To the OP: how many you can manage is going to depend a heck of a lot more on the quality of the code on your server than what net protocol you're using. For instance, if you go thread-per-connection you are effectively limited to 300-500 clients, even being optimistic. Go with a decent asynch-I/O system and you should be able to hit multiple thousands with little difficulty. If you know what you're doing, there's no reason why you should stop short of 5,000; on a brand new PC I'd be surprised if you couldn't hit 10,000.

Whats a thread? I'm working in procedural-C remember? [razz]

Quote:

Original post by Anonymous Poster But...you're normally doing an awful lot of work, and it can take an awful lot of optimization of your code to allow you to do non-trivial calcs on each client without burning performance.

Checks:
1 - Is the username correct?
2 - Is the password correct?

lol, its just that simple. Both the username and password are 10 bytes each. Considering I don't use any of C++'s automated "Safe" features, my C code runs at near assembly level performance, so it shouldn't be a problem, even with 1000+ clients (Server is an AMD 34/64bit 2.00Ghz [Wicked motherboard included]).

I think I'll google wheter or not C programmers use threads. I know what a thread is, but I always thought it was just for C++ programmers.

Quote:

Original post by pTymN Nothing could possibly make more sense than implementing your own reliaable UDP protocol. 1) UDP can handle various firewall situations better. 2) You can customize how your bandwidth is used as far as packet garenteeing. When you use TCP, you hand control of these things over to its protocol, and network bandwidth is the single tightest bottleneck left in computing, much worse and more expensive for a user to upgrade than memory or video card or CPU speed. 3) Check out Clanlib networking or Torque net library, both use reliable udp protocols and are MUCH MUCH better for sending real time game information than tcp could ever be.

Wow, so much information!

Thanks! [smile]

Quote:

Original post by graveyard filla well, i just think that it's pointless. i DO see how its usefull for sending things like character selection screen, character deletion, log ins, character creation etc. we wouldn't want someone spoofing a packet and deleteing a character on someone's account.

All that is handled via Web interface. CGI sends the paraments of the webpages to programs I've written, that generate the account.[/quote]

Quote:

Original post by graveyard filla however, i just don't see the point in doing it with movement or firing packets. i mean, the server should track who is sending us a packet in the first place, so we shouldn't even need to verify that this person is legitmately the person he says he is.

These 20 bytes save me from having to write all the stuff you just described. Considering I'm using UDP, its alot of work! I'd have to implement an ack system, and lots of other things, to the point where its just not worth it over a mere 20 bytes. Especially since I'd like to have my game running for a few months so I can evaluate its popularity before I go and design a commercial grade netcode: even than I might leave it in, since even some commercial games.. BattleField 1942 have some high packet sizes.