Netcode RPC reliability

In the current Netcode preview on the Package Manager (0.1.0-preview.6 at the time of writing), from what I've seen in both behavior and code, it appears that RPCs can silently be lost if more RPC data than can fit one packet is generated in a single frame. Aside from this happening silently, this is devious in at least two ways: once there's a decent number of systems generating RPCs, it becomes hard to reason about how many and which RPCs can theoretically be spawned in a single frame, so to design around this is... troublesome. Also, the number of bytes that can be written in a single frame appears to depend on what the underlying transport layer can accept at the current time. This, I assume, depends on the current remaining capacity of the underlying pipeline's send buffer. So it can vary.

Since it may already be possible for RPCs to be delayed one or more frames if driver.BeginSend fails (although this might only ever happen when the connection is broken, not sure when NetworkSendInterface.BeginSendMessage may return != 0 otherwise?), and mostly because it doesn't matter for my use case, I patched the RPC logic to also track the size of pending RPCs so the send system can always send as many RPCs as possible without running into the danger of splitting RPC data up into separate packets (which could then lead to broken deserialization on the receiving end) and keep the rest for later. If anyone is interested, the patch is attached. Not rigorously tested though.

Now, my question is: was this a deliberate design decision? I couldn't find anything in the docs about it.
If yes, what is the suggested way of sending data in a reliable way then? E.g. current game state of non-ghost world state for clients that join in late (state that is non-ghost because it's too big for that, e.g. heightmap data).
If no, how likely is it that this will be addressed and what could an outline of an official solution to this problem look like? Thanks!


PS: I tried to find topics on this on the forums, but it's hard when the search doesn't allow search terms that are only three letter long, such as "rpc"... so if there is a topic on that already, apologies!

 

@timjohansson can you answer above question? I also faced RPCs lost problem when I call rpcQueue.schedule multiple times per 1 frame.

 

@timjohansson Reported. I attached reproduced project. Thank you for your support.
I would appreciate it if you could include this solution into next release.

1261375
RPCs can silently be lost if more RPC data than can fit one packet is generated in a single frame

 

@timjohansson I checked the 1261375 issue (https://issuetracker.unity3d.com/is...fit-one-packet-is-generated-in-a-single-frame) and it seems to be fixed in 0.3.0.
Thank you for your quick support!
Could you tell me when it is available? (Actually our project will be released soon with netcode. If the bug is fixed, it is really happy for us.)
Or could you give me the package file if possible before 0.3.0 package release? We'd like to check it.

 

@timjohansson Hi, I know your are busy and sorry for rushing you.
We really want your help to use latest 0.3.0 netcode package if possible. Thank you in advance.

 

"You are correct that RPCs cannot handle too much data"

What's too much data? And how would you identify this prior besides intuition?

 

@timjohansson when is 0.3.0 going to be released? Or like Pocketpair askt is it possible to get a version with the RPC fix in it?