When the client not responding doing a heavy load task and the server execute a multicast event the client does not receive the action but shouldn’t the event be put in buffer that the client access when he is responsive ?
Is MC function reliable?
Reliable RPC is not the answer to instability since if the Client is very unstable the reliable RPC’s will mound up and kick the player.
Use Replicated variables instead since they are much more “reliable”. Replicated variables don’t mound up since they only request the latest update and can skip intermediate updates.
Yes the event is reliable
my problem is not with variables the event is not reaching the client
You can create response accept function and call MC function until you’ll get response. But as mentioned above client will be kicked by server if it will stay too long computing. Leave computing into threaded or for server.
it only for 3-4 seconds and the client is not kicked but didn’t receive MC event
Have you checked the log for warnings and errors? It could simply be that the client stalls and doesn’t open a connection before the RPC is sent out from the server. Only clients with active connections to the Actor will ensure reliably events.
I still recommend you change the event into a state variable and use that as an “event”.
TLDR: Is your client timing out too soon because of network latency and bad packets, resulting in unfired RPCs?
This sounds basic and unrelatable, but I found similar issues at the core of my network that manifested with the appearance of logic issues in the engine. That being said, I had to check my outgoing packet loss with ping tests to determine whether or not the connection was solid.
Turns out I had packet loss resulting from some equipment such as an SSD that produces RF that effectively would scramble internet signals and cause packet loss. This packet loss can be translated to the engine as ddos attacks as the packets appear to be trash which get kicked to a certain extent. Steam Net Drivers are much more sensitive than the default drivers… The result is that the connection would timeout the client and reliable or unreliable RPCs would basically just not fire and look as if I had bad logic. If it was severe enough the client would get kicked.
I fixed my issue by resolving my external internet interference and also ensuring that that I determined a greater timeout response in the INI file so that if the connection became unstable that the client wouldn’t freeze and get kicked in various ways. However when the connection stabilized the RPCs would fire all at once like a lagging game player…
I’m not sure what the Net Drivers default to in engine for a timeout response, it’s apparently not very long…
By adding something such as:
[/Script/OnlineSubsystem.IpNetDriver]
ConnectionTimeout=60.0
into my INI file appropriate to your specific net driver that resolved a lot of those RPC issues. As far as I can tell, it appears that when the signal is trash the RPCs would just sit waiting to get fired, but ultimately didn’t (I guess) because the client was timing out… That doesn’t necessarily resolve network latency, which may manifest weird issues like you’re describing. Also, apparently these RPCs must be serialized so long naming conventions can add critical time to the que and clog up the que. (I’m currently testing this for performance over a dedicated network, I’d have to get back to talk about real-life scenarios).
My problem is not with network latency its with the game thread being frozen getting data from data base btw the ConnectionTimeout is 300 in my project