Actually Syncing Connections has little to do with physically slowing down the players computer. In-fact my point above is that most people seem to think that capping the Sync Rate in DB/P means it'll work identically on all system.
This just isn't true.
For Networking though you have to think, outside the box on how your Syncronising the Connections.
Technically speaking when a new user logs in to a game what you want to do is find out how quickly it can send data. Every computer is different.
Games like Half-Life 2 (and right back to quake), solve this issue by setting something known as NetSpeedRate. What this does is let the Server and Client know when they can expect to see the next data packet.
For example a Network Speed of 15000, would mean that every 150ms you send & recieve another packet. This prevents server overloads from too many calls per second.
Personally the way I do it is through a check System.
-> Send Data
-- Check For Response
if Response = 1
<- Get Packet
^^ Repeat
The Key is to send the players entire packets containing ALL of the data they need. Well atleast conserning the Players, stuff like chat can be done seperately because it's not a major issue if chat lags. (annoying for timed strkes but better than being owned by a LPB
)
With this Systen it basically limits all of the Data to bursts.
It's a very good system that's been in-place for years though. Rather than limiting the game itself, you simple limit the data calls being made.
The difference in the speed of the connection is instantly noticeable too.
Again, if you like I can write up some simple code to show you exactly what I mean. Another good point about this method is you can setup limits Per Player. So thier connection speed will only cause the minimal ping effect on the server itself, and if done right you can almost eliminate it.
