Original Post
I'm currently writing a client-server platform for real-time multiplayer games using lidgren/C#. It's going extremely well, with "smooth" results even up to fairly high latency (500ms or so). Anyway, to make some optimization decisions, I need to know a few ballpark figures, namely how many packages per second is reasonable for the server to be sending out (on a single port). The platform works by maintaining an "ExactState" on all clients and on the server. The only data sent across the network is what I call "EventRequests", which are essentially user inputs. This is of course enough to maintain identical "ExactStates". To get smooth motion, I use varioius tricks such as a "predictiveStates", interpolation techniques and other stuff clever stuff like input predictions. Anyway, at the moment it's very efficient: one tiny packet is sent to the server per keypress/release per player. These are set into a fixed order on the server and sent back to the clients in a bundle of around 10 server-ticks (assuming 60hz server, this would be around 6 per second). These ordered bundles of EventRequests I call "GameStateControlPackets". Now the issue here is that an additional, worst case, X ms of latency (where X is the length of time to build a GameStateControlPacket") is introduced between clients. This is because, when another client requests an event, this request must go to the server, and then only gets sent out with the next GameStateControlPacket. Currently this introduces a worst case of 160ms. This is a lot in a real-time game where enemy positions are critical to gameplay, plus it's ontop of the actual network latency. To get around this, I would like to immediately send out "PredictionRequests". These are sent out by the server to all users as soon as any EventRequest is received from a client. Of course, since they're not in a fixed order, identical state cannot be maintained by using them. However they are used in the predictive part of the client. Most of the time they're correct, and when they're not, the resultant "incorrect" state is interpolated into the ermergent ExactState. Looking at a few worst-cases: Let us say the server is hosting 25 games, each with 4 players per game. Now let's say players are going a bit wild and making 10 press/releases (triggering EventRequests) per second. This would mean that the server is sending out (10*4*3 in each game) * 25 = 3000 of these PredictionRequests packets per second. (Note that they are tiny UDP packets, and can be sent unordered and unreliably) I have no idea if this is totally unreasonable. At a glance it does seem like rather a lot; especially when you consider that, without these "PredictionRequests", the server would only be sending out 625 "GameStateControlPackets" for the same scenario (25 games with 4 players each). But actually, even 600 per second seems a lot: The data I'm sending across is often only a few bytes, but I'm sure there is overhead associated with each UDP packet. Any insight would be greatly appreciated. Questions 1) What is considered "a lot" of traffic for a typical server to deal with? 2) Would assigning a separate port per game give better performance? 3) Will Lidgren be sufficient for this? (I'm having a really hard time finding any sort of documentation on the library)
