possible cure (not 100% but I think it could help a whole lot)
when player joins (and possibly between rounds too) the server could send some packets to the client and wait for replys keeping track of how long it took for the responses, take an avg of these values and then limit its packet output rate to that client using the calculated time
I know that during play timing will vary but Im sure this would help remove most of the warping and random deaths
what you guys think ?
client packet loss
-
iceman
- Reverse Adjust Outside Corner Grinder
- Posts: 2448
- Joined: Fri Jan 09, 2004 9:54 am
- Location: Yorkshire, England. Quote: Its the fumes, they make one want to play
- Contact:
client packet loss
He who laughs last, probably has a back-up
sorry about the large animated gif
Good idea. The server can surely use more information on how its activity affects client lag ( and the client could use that info, too ). However, there is a lot of non-network stuff going on between the rounds ( reloading of graphics ).
How about the following modification: The peers send package acknowledgement messages anyway, it would be possible to add timing information to that. The sender would then have complete information: It knows when it sent the original packet and recieved the ack anyway, and now it would also know when the packet arrived. The real ping could be calculated from the "average minimal" round trip time ( as is done now ). Exceptionally long times from sending to receiving, if correlated with exceptionally large packets sent before, are an indication that too much data is sent to that particular client. The connection could then be throttled.
Downside of any automatic throttling mechanism: you have to ballance it. Trottle too agressively and fluctuating connection quality ( stupid user playing and file sharing at the same time ) will set the bandwidth too low, throttle too little and the bandwidth will be higher than the line allows.
How about the following modification: The peers send package acknowledgement messages anyway, it would be possible to add timing information to that. The sender would then have complete information: It knows when it sent the original packet and recieved the ack anyway, and now it would also know when the packet arrived. The real ping could be calculated from the "average minimal" round trip time ( as is done now ). Exceptionally long times from sending to receiving, if correlated with exceptionally large packets sent before, are an indication that too much data is sent to that particular client. The connection could then be throttled.
Downside of any automatic throttling mechanism: you have to ballance it. Trottle too agressively and fluctuating connection quality ( stupid user playing and file sharing at the same time ) will set the bandwidth too low, throttle too little and the bandwidth will be higher than the line allows.