Hiya,

while working on mprEdit i started thinking about the way the netcode of LFS is working. I think most people here agree that lfs multiplayer is working remarkably well, given the nature of the internet.
While i am trying to figure out how to get hands on the lapcount or racetime information i tried to get a bigger picture of the communication.

My theory:
Client sends controller input to server
Server collects all clients controller input
Server sends to all clients the controller input of all other clients
Clients do physics calculation (the actual movement of the cars)

And every now and then (few times a second) there is a "position" packet containing the actual car position from the server to all clients to be sure that each players position is in sync on all clients.

What i am unsure:
Who keeps track of the current standing in the race? Server, Client, both?
Who decides when to display a split time, when a lap is finished, when the pit entry/exit line is crossed? Server, Client, both?

So what is your opinion? Do you agree/disagree? Any knowledge? This thread is open for all speculation :-)

Quote from MikeB :

...This thread is open for all speculation :-)

Well in that case i reckon there is actually a little man driving each car

Magic, maybe pixies as well

Quote from nikimere :

Well in that case i reckon there is actually a little man driving each car

Quote from Bean0 :

Magic, maybe pixies as well

Well, at least that's a start for discussion

the netcode has its basic functions like all other multiplayer games....

it collects the coordinates, pitch, yaw and roll... EDIT: and "maybe routes" if there is a packet loss (often seen if a car runs straight ahead and in the next second he finally drove around the corner )

how the physics etc are implented, don't know and i think its scawens secret

Quote from MikeB :

My theory:
Client sends controller input to server
Server collects all clients controller input
Server sends to all clients the controller input of all other clients
Clients do physics calculation (the actual movement of the cars)

And every now and then (few times a second) there is a "position" packet containing the actual car position from the server to all clients to be sure that each players position is in sync on all clients.

Totally agree with you, and we already know that the current server doesn't do any physics calcs at all (Scawen has posted this somewhere).

Quote from MikeB :

Who keeps track of the current standing in the race? Server, Client, both?

I'd suggest that the client does that, rather than the server.

Quote from MikeB :

Who decides when to display a split time, when a lap is finished, when the pit entry/exit line is crossed? Server, Client, both?

I would like to say that it's the server, but I think somewhere Scawen has said that theres no knowledge of the maps on the server either, so combined with the fact that it's physics-less, I'd guess that the client is authoritive over positions and that the first client to inform the server gets priority.

Quote from MikeB :

So what is your opinion? Do you agree/disagree?

Totally agree, but I think that the way in which it appears to work is a bit unorthodox, and it partially why cheating is occasionally such a problem. Is the server was aware of the physics of the vehicles it would be far more likely to prevent speed hackers, etc.

Just a guess but I would imagine that more than controller info is sent to the server. If just controller input was sent to the server, it would need to calculate all the physics, to figure out the positions of the cars.

I imagine the client sends speed, orientaion, postion, revs, steering, brake and throttle in each packet (probally more). This would then be sent on to clients by the server. So the server doesn't need to be that smart. ( It may even use keyframes which contain all the data above and smaller frames with just position and controller input, missing info in smaller frames would be interpolated from keyframes:shrug

The trouble with this is the position info is always late and the bit the impresses me with lfs is how well it can approximate where the car will currently be based on old data.

Quote from AaronDev :

It may even use keyframes which contain all the data above and smaller frames with just position and controller input, missing info in smaller frames would be interpolated from keyframes

I'm amazed that you've just repeated exactly what has already been said here? LFS does calculate physics for each car, and it does interpolate (again, has been stated somewhere in the past by one of the developers, iirc). The fact that the cars "snap" into position suggests exactly that this happens and thats exactly what has been suggested by myself and MikeB??

If a server is running at 4pps, it might not be unreasonable to suggest that the first 3 packets are controller input and the 4th is a "master" packet containing additional information, such as position, orientation, etc.

Quote from AaronDev :

The trouble with this is the position info is always late and the bit the impresses me with lfs is how well it can approximate where the car will currently be based on old data.

The quake prediction seems somewhat more reliable in my opinion, not to mention that the server is also authoritive, rather than the clients. For instance, if you hit an object in LFS it gets simulated on the client only and it may hit a car on one client, but not another, which gives rise to the behaviour we see in LFS today (just look at any large incident in detail and you'll see what I mean) (again this was posted by Scawen explaining why its not possible to create a football at present, as objects are not governed by the server). This also holds ramifications for cheats.

Perhaps it's time to play a bit of LFS and hook up a network monitor and see whats going on, rather than actually on the little netcode that it uses?

Quote from the_angry_angel :

I'm amazed that you've just repeated exactly what has already been said here?

Sorry had the page open earlier and didn't refresh before posting. I agree with your post.

I didn't know that the server had no knowledge of the maps.

Quote from AaronDev :

Sorry had the page open earlier and didn't refresh before posting. I agree with your post.

Heheh, sorry

I've done a quick dump of a clean virtual machine running Windows 2003 server, with no other network traffic except me connecting to it, joining the race, doing a lap and then leaving (I've attached it below if anyone else wants to start looking at it - pcap format I'm afraid). I've also done the same, but just sat in the pits, but didn't start the packet capture until I was in the server.

At 4 PPS it appears that 4 UDP packets get sent a second, all 68 bytes in size.

This is punctuated by various TCP packets;
* A 6 byte packet - I'm guessing some sort of keepalive perhaps
* A 59 byte packet every 5-ish seconds (there seems to be some sort of contraint on this - I've not figured out what this is exactly - I'm guessing it coincides with another packet and its being amalgamated perhaps)
* A 11 byte packet
* A 27 byte packet (?)
* An 80 byte packet (?)
* A 64 byte packet (?)

There's definately a sort of pattern. My brain needs food now though...

Thats some interesting stuff... This means:
If our assumptions are true, this means the server is basically a braindead package repeater
And each client takes care for

• track data/layout
  
• physics
  
• time / split times / results
  

So, coming back to the original task i have with mprEdit:
That would mean that the packages sent to the client (and then saved as mpr data) do NOT include any sort of time/lap count/... information - This is all calculated on the fly during playback of the replay? Then i will soon be out of ideas how to split a replay at a certain time/lap

The point is that the information i am seeing in the mpr is somehow confusing. I (originally it was WolleT) found the following pattern to occur after all header info:

• 2 Bytes timestamp (rolling over at 65534)
  
• 2 Bytes signature "FC 00"
  
• 1 Byte, maybe some kind of type information
  
• 1 Byte "00"
  
• <actual data, mostly unknown, varying size>
  

So whenever the replay starts with a timestamp followed by "FC00" it plays back without problem.
The point is that the "timestamp" is not really a timestamp - It is increasing with every packet, but there seems no relation to real timeinformation. It is definitely not milliseconds or sth like that - It seems unrelated to the replay time.
Also the actual data varies in size from a few Bytes to Kbyte...

I would guess that these packets are the "position" or "master" packets, followed by controller input, chat messages etc. of all players. But i did not find any proof for this idea yet

angryAngel, maybe you can find some hintes when analyzing the network traffic - i am unskilled in that area

im thinking your best of asking scawen about this, it sounds very complex

Quote from mcgas001 :

im thinking your best of asking scawen about this, it sounds very complex

Yeah, i know But i do not want to harass the Devs with these questions - and i also don't think they really want to publish info about the replay format in public...

Erm, they kinda did.
http://www.lfs.net/?page=SPR
http://www.lfs.net/?page=MPR
But just the header.

I wonder how hard the devs are laughing at us.

Quote from Dygear :

Erm, they kinda did.
http://www.lfs.net/?page=SPR
http://www.lfs.net/?page=MPR
But just the header.

I wonder how hard the devs are laughing at us.

Hehe, course i know the header documentation But the interesting stuff for me is the later, undocumented part...

Quote from Dygear :

I wonder how hard the devs are laughing at us.

Probably quite a lot, although a lot of what we supposedly know is seems to be fairly accurate..

a far off land with real XRTs with people who never leave their racing suits, and with a massive scrap heap next-door full of totalled GTRs and bf1s from all the mishaps in oval junkies :P

p.s no wonder lag is such a biatch :P