I am wondering if you could clear something up for me. This is what I think I know:
Replicated uproperties are always reliably replicated
If server tick is faster than network update; replicated properties are stored in a history buffer (which for exceptionally harsh situations need to be “dumped”)
Question1: What does UE use the history buffer for?
Question2: Once the network update eventually fires, will the entire history buffer be sent or just the last update/entry?
Bonus: Is there any way to configure this behavior in Question2 to be one or the other?
Hi. The part of code is not easy readable, but I think this story buffer is used mostly to deal with network failures. Even reliable connection is not absolutely reliable and some packets can’t be delievered sometimes. Normally UE stashes all history to the single packet (maybe something is left in the history buffer if packet is overflowed), but keeps these changes in the history until receiving will be approved. If packet is still not approved till the next sending this data will be merged again with the new history. History can be overflowed, but it can happend only when client losts connection for a while. If server trying to replicate data rapidly new portions of it will be automatically merged to the head of history without creatiing a new entry. So, UE always send single bunch of data regardless to the length of a history buffer.
Also some “incomplete” history entries can appear - it seems that these entries are being filled at the moment of sending, but they just ignored and can be pushed away, so I think it shouldn’t happen normally.
Thanks for the clarification! That actually clears up some question marks. And also brings up some new questions Tried to read through some code and the “dump/overflow” indeed seems to happen when the server has been ticking too much and not been able to make a successful replication, e.g. when a client is unresponsive. One interesting thing seems to be that when an overflow occurs it will trigger a “forced” replication. This is the “dump”. This is in contrast to my previous belief that the server just cleared the history buffer and moved on.
Perhaps is not ideal for this type of continued discussion, but anyway: I made a pretty picture of my understanding here.
Referring to the image, let’s say I’m replicating one FVector property currentLocation and nothing else:
What does a bunch consist of? Only the FVectors or more data? How much overhead is there?
In the second netUpdate, as I understand it, there will be two currentLocations. Is there a way for me to tell unreal that previous currentLocations are not interesting to anyone and they should not be considered for replication if there are newer values. For example, I’m seeing an interesting method UCharacterMovementComponent::CanCombineWith, but perhaps that’s just for merging into the “current” historyBuffer item?
Your image looks good. I discovered little differences in real code - actually server can produce lot of history entries because it creating a new one each time when called FRepLayout::CompareProperties but it shouldn’t cause any problems because CompareProperties can automatically merge entries if history is out of room. But exactly after comparing properties called SendProperties which stashes all what it can and send it. To order packets used PacketID incremental field, but when a bunch of history entries sent they marked with one ID. If this packet dropped all history entries with this ID marked to resend and will be sent again. A client arranges packets using ID and ignores obsolete packets if got a packet with greater ID. Every bunch contains header with information about properties owner and raw property data (binary). Some properties packed with reduced accuracy and some properties are delta-compressed. You have to find UActorChannel::WriteContentBlockPayload for details.
Tried to read through some code and the “dump/overflow” indeed seems to happen when the server has been ticking too much and not been able to make a successful replication, e.g. when a client is unresponsive. One interesting thing seems to be that when an overflow occurs it will trigger a “forced” replication. This is the “dump”. This is in contrast to my previous belief that the server just cleared the history buffer and moved on.