I think it's time to revive this thread. Since the appearing of the "AutoX Compo Test Server", i found new useful informations to help scawen dig into this problem and see that it's not an ISP bug.
In the following link there are my considerations about this bug:
http://www.lfsforum.net/showthread.php?p=174173#post174173
since i experimented this problem on autox server, it is clear this is not an ISP bug accordingly to: LFS network debug, 100% ping succesful, 100% traceroute succesful.
what autox server made me realize is that servers with InSim applications are more prone to this problem, in other words the problem is in lfs somewhere, but InSim seem to stress it more and make it more frequent (the autox server is the worst in this regards).
so, since then i went around lfs servers and test my hypotesis:
- on regular servers (i.e. without InSim applications) it never happened till now...but i remember in the past to be happened
- on servers with InSim applications it is more frequent and the more InSim messages, the more frequent the problem is...
- the problem is triggered by spectate/join actions, i.e. if i connect to a server and i never go to spectate, the problem seem to never arise!!!
(<- important!!!)
- my guesses are that when under udp flood some lfs queue of packets overflows and it misses to process some udp from clients...this is is irrilevant for udp position, but missing the udp command for "join to race" causes this problem. Another possibility is that the server is running on a windows pc with unpatched tcp.sys that limits connections, in that case the problem would be of windows, but i don't think it is the case
since the lfs network debug clearly shows that udp packets arrive correctly to lfs!!!
so to
summarize:
- udp packets arrive to lfs according to lfs network debug, ping and traceroute (-> verified!)
- "invisible car bug" is triggered by spectate/join sequences of actions
- "invisible car bug" is more frequent on servers with InSim applications