@Lazza: In a brief ... theoretically it shouldn't, but it looks like it does. A not too complicated explanation of lag in online gaming can be found here:
http://en.wikipedia.org/wiki/Lag_(online_gaming)
Approach of a simple explanation:
In general client-to-server performance is a matter of bandwidth and the time data packets can be handled through all involved layers of a protocol stack in a hopefully very timely fashion from the client-application-layer to its server-application layer and vice versa.
In our days bandwidth ain't a problem anymore, if you a running your server in a sophisticated data center with a rock solid and guaranteed data rate uplink of approx. 100 mbit/s. For example: by default the rF DS can be configured to reserve 8042 kbps for up- and downlink separately. With the multiplayer.ini value "Max Data Per Client="64"" you're gonna tell rF DS, no matter what the client is requesting, you will only allow them to use a maximum of 64 kbps at most in bandwidth. This is more than enough, cause monitoring the traffic on TCP 34447 and UDP 34297 and 34397 with a tool like wireshark came up with an average bandwidth usage of approx. 8 - 9 kbps. By the way. The minimum value you can assign for this parameter is "10". So with a value of "64" you got an approx. 7-fold-safety concerning your bandwidth for client-to-server communication. rF DS is able to reserve 104 - 1 = 103 slots for multiplayer gaming. The -1 slot is the dedicated server himself. So in case you allow a client only to consume 64 kbps at most and multiply this with 104 you are gonna end up with an effective bandwidth consumption of 6656 kbps. But why not using the other 8042 - 6656 = 1386 kbps (17.23 %) !?!? of the maximum reserveable bandwidth? Cause in IT there is some sort of a rule of thumb, that tells if a resource is used constantly around 75%, it is claimed to be actually fully loaded and we need the other 25% to compensate peeks. Or in other words: If one is able to lift a 100kg as a maximum and I add 1 gram to the weight, this one will collapse under the "overload". Concerning the "Max Data Per Client=" parameter we actually got a some sort of QoS implementation at the application level.
Another maybe more important thing is how data packets can be transferred between client and server. Normally online games are based on UDP data packets. But like Jeremy already stated, the netcode of rFactor uses a session oriented TCP connection to "monitor/control" the UDP data stream. Cause UDP doesn't actually care if packets can be transferred successfully between each other, TCP does and is implemented as some sort of control instance for the actually gaming data. Jeremy, please correct me if I am wrong. So let's say we currently got 52 clients connected to the dedicated server (hopefully not a Windows XP Server with a Realtek On-Board Desktop NIC) and one client is for whatever kind of reason, producing a high latency from about 1500 - 1800 ms, which by the way is quite a lot. Although everybody is talking about multitasking, at the very very very end there still is some sort of a time slice implementation to serve requests. I really don't like guessing, but at this point I have to, cause I don't know the real implementation of ISI's netcode to handle those high latency clients by either trying to compensate this by shortly spending more bandwidth to this high latency client, or if the process of serving this client just stuck there for that higher period of time and the other clients are influenced by this "wait state" caused by this one and only high latency client until the client is dropped because of loss of communication causing also a laggy connection for all the other clients connected to the server application.
But like I already stated, this is just a guessing and the following site (
http://wiki.ctwug.za.net/Ctwug_servers#Game_Servers ) actually inspired me to think about QoS and rFactor DS and maybe give it a try to stabilize rFactor Events with a major focus on Endurance Racing ...
Cheers
Frank
