Under which circumstances does LFS decide to use TCP packets for the position updates? I've noticed that when it does so I get much smoother gameplay and I do not lag to other players - because of TCP flow control levelling out the saturation of my outgoing bandwidth I assume. Is there some way to manually control this selection?
TCP packets for position updates
(9 posts, started )
TCP packets for position updates
somehow i suspect this thread will end in cheating as a theme.
Think so? Hmm... Now you got me more interested as to how that would happen than in an answer to my query...
Huh, I think only the Devs can truly answer that question. AFAIK most of the time UDP packets are used, because they are faster and don't need that much bandwidth. Maybe there are some TCP packets thrown in there to get some "secure" positions, but I don't really understand why Scawen should do this. Actually I think LFS doesn't ever use TCP for position updates, only for important things like tyre temps, damage, etc.
Which is why it intrigued me that in specific servers that I joined I got a "Requested TCP packets for position updates" message. Unless that's some redundant debugging message forgotten on. However gameplay as I mentioned was noticeably smoother on those servers (and they didn't really rank high up in ping rates, one was even in the >150ms range).
I'd prefer TCP connections not used at all (I dont know if they are), since even a very short network problem could cause the TCP connection to be cut and thus you would get disconnected from the server. I have got dropped from a server during long races and that is always quite frustrating, I dont know the cause of those disconnects but if LFS uses a TCP connection to the server then that would explain them...
Guests can manually select this emergency fallback system by using CTRL+T
LFS does this automatically if your computer has some kind of problem receiving UDP packets - for example a few routers / networks seem to be unable to correctly pass UDP packets to their intended destination computer.
If you select that option then you will receive (but not send) car position updates in TCP packets. There is no possibility of sending positions to the host using TCP - the ability to receive UDP packets efficiently and correctly is an absolute requirement for a host.
The use of CTRL+T is not recommended unless you have a fault. UDP packets can arrive faster and do not worry about error correction. Error correction is not required for car position updates. The solution on receiving a corrupted packet is to discard it and wait for the next one. Due to the error correction, TCP can cause long lag issues and timeouts.
LFS does this automatically if your computer has some kind of problem receiving UDP packets - for example a few routers / networks seem to be unable to correctly pass UDP packets to their intended destination computer.
If you select that option then you will receive (but not send) car position updates in TCP packets. There is no possibility of sending positions to the host using TCP - the ability to receive UDP packets efficiently and correctly is an absolute requirement for a host.
The use of CTRL+T is not recommended unless you have a fault. UDP packets can arrive faster and do not worry about error correction. Error correction is not required for car position updates. The solution on receiving a corrupted packet is to discard it and wait for the next one. Due to the error correction, TCP can cause long lag issues and timeouts.
Aha, thanks for clearing that up.
I guess it must of been a different reason then that I'm getting better results on those hosts and the selection of TCP packets was just coincidental.
how exactly
TCP packets for position updates
(9 posts, started )
FGED GREDG RDFGDR GSFDG