This is more of a stab in the dark question for those who are more in the know than I am about these things....

If I am not mistaken, at the moment LFS uses TCP and UDP packets. However, alot of people at the moment seem to be rather suceptible to packet loss over their broadband network, in particular UDP packets as they have no/less parity checking (correct terminology?). I am one of those people as you may have gathered from my thread in the Tech Help section.

So what I am suggesting is, is it possible to use soley TCP packets for LFS? If my quick research is correct, TCP has better protection/protocols for ensuring all data is properly sent/received.

This is probably one for all you Coders & Net Gurus out there, but to be honest probably only Scawen could answer this as it is his netcode! It was very good for me until now

I know this sounds a little bit selfish or silly to implement for such few people, but with so many ISPs overloading their networks these days packet losses will most likely become more and more apparent. Sadly I think it will only get worse in the near future as more and more people get connected and more demand is placed on the system.

So what are your thoughts/suggestions on this?

There's a reason we don't only use TCP packets, and it is speed. A TCP packet has much more overload and requires the client to send back an "ok, I got it" to the server. A UDP packet is more like fire & forget, which is useful for data that has to be updated very often, and where it doesn't really matter if one or two updates get lost once in a time.

So, for important packets that absolutely have to reach the client (like "race starts"), TCP is used, for any position updates, UDP. If we were to use TCP for everything, not only would that cause a big traffic increase, the pings would rise considerably, too.

Then imagine there was a short traffic problem so some position-TCP packets couldn't be sent. LFS would try to send these packets again and again, even though they contain completely worthless information because in reality the car has moved somewhere else anyway.


Sorry but no, that wouldn't work.

Yeah, I sort of knew it would create more traffic, but I was unsure as to how much more.

Another reason I ask is that games like Doom3 still run perfectly online for me. Is that becuase it relies soley on TCP packets? Surely LFS isnt that much more of a bandwidth hog?

I seem to recall that you can force LFS to use TCP packets only, maybe rummage through the config files or search the forum. I'm sure Scawen mentioned it a while back.

But if memory served, it was just there as a backup for people who couldnt get UDP packets through the firewall, there are performance problems I think.

Pressing CTRL+T forces LFS to use TCP. But I dont reccomend it, you are excessively loading thr server and if there is no serious reason why to do that, keep up on UDP.

I dont know if Doom3 uses TCP ur UDP, but Doom3 should be less dependant on bandwidth, there are just few things to send. LFS synchronizes more variables than Doom3 IMO.

Yes, colcob and MadCatX are right. If I remember correctly its Control + T to revert back to TCP positioning packets.

To clarify its the extra packet size, its the verificiation that TCP must do for each packet, that makes it unsuitable.

As for Doom vs LFS they're a slightly unfair comparison (due to the number of variable sent - theres only a handful of "actions" to send in a FPS), but LFS could be modified to use a Quake3-esque networking model. The current Quake networking model basically boils down to the fact that every packet, regardless of its under lying architecture, is assumed to never reach the client. This means that the server needs to beable to have the last X steps, and beable to understand how to regenerate a "shortcut" to those steps, without having to transmit them all again (my understanding may be a little flawed, but its roughly it in a nutshell). This does mean that the server is more than a packet distributor and sanity checker, and needs a lot more logic. Also, as I understand it, the Quake packets are subject to huffman compression.

Of course, without knowing the netcode LFS may already do this, and for whatever reason it isnt enough.

Thanks for the tips guys!

Basically online play is impossible at the moment, and so I might try this out for a while.

Does this apply to the Server List aswell? It is REALLY slow too! Anyway, ill give it a try and see.

Quote from MadCatX :

Pressing CTRL+T forces LFS to use TCP

Ohhh, nice to know

Quote from AndroidXP :

Ohhh, nice to know

except that after a quick test i still lagged out on an empty server..........

when you press CTRL-T it says "Requesting TCP Packets for positional updates", however there is no confirmation of this request.

edit: In the CFG file would it be 'Conn To Master 0' ? Otherwise I can just do it in game.

Quote from colcob :

But if memory served, it was just there as a backup for people who couldnt get UDP packets through the firewall, there are performance problems I think.

I am pretty sure that UDP packets arent being blocked in my case, but is there anyway to check this? I am sure TCP/UDP packets are enabled for when I host a server, but I do not usually use a seperate rule for normal LFS.

A crap connection is still the #1 cause due to the results I get from Ping Plotter, but ill check out the firewall for UDP allowances anyway.