Every single time I try to write a server for my game to enable online play, it ends up a huge, ugly switch statement, and gets error-prone and buggy quickly. Does anyone have any idea how I should design my game servers?
It really depends on how your packets are formed. For Minecraft, each packet is different depending on what you're doing. You can set a callback depending on the packet header then pass the rest as an argument of that callback specific to that packet, using a union to hold each type of function pointer.
Other than though, not much more you can do. Can you show the ugly, error-prone parts so i get more of an idea of what you don't like?
Big is fine if it works! My mentor owns an ISP and we were talking about this yesterday. Do you understand the concept of latency in terms of Internet connections? For instance you could be getting 22 Gb/s but have a slower rate of exchange than someone with a 2 Mb/s connection, the width of the pipe doesn't necessarily mean you will get data quickly (request time to start of transfer time), it just means bigger bundles of data can get through "faster."
As a game developer that's a big reason to bundle as much as possible into your transfers, and that's where things like dead reckoning and other predictive methods come into play.
As far as how you design your server? Design your protocol to need less data transferred, transfer as soon as possible when you get data (so keep your code as small as possible, minimize the logic required to serve data), and don't worry about monster code as long as it is consistent.
What kind of bizzare low level networking are you doing? There is no reason to send the address and timestamp like that. All your packets should consist of a size field, followed by size bytes of data, and your high level code deserializes that data.
Why in the world would you use UDP for text chat? UDP should only be used in cases where you don't care about the unreliability. Trying to add info the the UDP packets to make them reliable circumvents the purpose of UDP entirely, as you're basically building a slower, buggier TCP.
Have to comment just from seeing this as I always wanted more info about it. To stay relevant to the topic I also implement checking packet IDs as a large switch statement and it always ends up getting really annoying to handle.
Everywhere you look you see people saying never mix TCP/UDP at it causes them both to be slower as they interfere with each other (I'm no networking expert so I just take peoples word for this). This is why people recommend to use "basic" UDP for movement + reliable layer on top of UDP for chat messages etc.
Eh... I doubt the credibility of that statement heavily. He avoids the argumentation that one affects the other as "complicated". I feel like he's saying, "If you play DotA 2 while streaming with Pandora, one will affect the other" which is true but... not realistically a problem.
EDIT: Also, who recommends UDP for chat messages? The only time someone recommends this is if they want to add features that TCP either conflicts with (such as a custom timeout mechanism or a more optimized reliability system) or they want to be more secure (encryption of lower level things).
Plug 'N Play network event handlers ahoy! Hope it helps.
* @LB -- I used to be 'the goto guy' for an online game that regularly had ~500 players on at any time. Meta-data like timestamps, checksums, and any other information that can be scraped up is crucial for logging, especially when a zero-day vulnerability pops up and players start exploiting a cheat.
What do you mean "seems like a waste"? The only waste here is your effort to replicate TCP in a less efficient way. With some of the networking libraries I have used, the difference between TCP and UDP is a boolean parameter.
I agree that using WinSock directly is normally not the best idea (I am very cross platform supportive). I have always used SDL_net as I am using SDL for my opengl window/input/audio anyway. Unless you are using directX I would get off WinSock and find a cross platform wrapper.
I don't see how coding a minor reliability layer on top of UDP for chat commands (in a game, for something like skype you would obviously use TCP) etc is "reinventing a protocol". Why use TCP here?
You've got it backwards: the question is actually "why use UDP here?"
TCP should be the default choice, and UDP should be used in cases where information loss is acceptable.
VoIP software like Skype and Google Hangouts most likely use UDP for sound and TCP for chat. Sound is a constant stream, so occasional packet loss is acceptable. UDP is fast, so the conversation often has a low ping.
Occasional packet loss for chat is unacceptable, and reinventing the wheel to make it 'reliable' is wasted effort when TCP is perfectly acceptable. It's fine if chat messages take a long time to arrive, even several seconds is perfectly acceptable.
I thought that, assuming you read up on what TCP and UDP were, when to use TCP vs UDP was obvious basic knowledge, but apparently I was wrong. I have a bad habit of making such mislead assumptions about common knowledge - this is not meant to be offensive.
I thought that, assuming you read up on what TCP and UDP were, when to use TCP vs UDP was obvious basic knowledge,
Yes it is obvious, when they are used exclusively.
Google "Mixing UDP and TCP" in 1 application and you will find more people saying "ehhh maybe not the best idea" then "Yes! Separate them out depending on what is needed". So movement uses UDP, chat uses TCP, you would assume item pickups/drops uses TCP, jumping uses UDP. Why does everyone say all of this mixing is a bad idea? If it is this obvious why are games like minecraft using exclusive TCP?
This may just be a rumor someone started and has gotten repeated too many times but I would like to see how much TCP negatively effects a parallel UDP socket with a reasonable amount of people compared to UDP handling it all. (I do not have the means to test this).
Or am I misunderstanding and you are saying TCP should just be used in games completely?