Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Client cant join a server if server is running reliable rpc

To reproduce this:

Client can join:

-Create a new project using THIRD PERSON BP template project

-Open level blueprint

-Add a custom event, set replication property to multicast, DONT CHECK RELIABLE yet

-Call the custom event on event Tick in level blueprint

Simply like this

alt text

-Launch the game with 2 clients, it work

now to reproduce the bug so the client cant join:

-Check RELIABLE property on the custom event

Is that even a bug or is it normal? if it isnt a bug how a client can join a game if the server is running a game with reliable rpc running on it ?

Product Version: Not Selected
more ▼

asked Sep 13 '14 at 12:06 AM in Bug Reports

avatar image

625 42 59 88

avatar image Snoxx Feb 05 '18 at 04:28 AM

i heard on a youtube tutorial that the RELIABLE check box is only there if you want the event to ALWAYS be called....no matter how much stress is on your network.

UNRELIABLE means that if your network has very little stress then yes the event will be called but if your network is copping a beating then it will call the event sometimes and sometimes it wont.

So only use RELIABLE when the event MUST be called. BUT you shouldnt be using event ticks for most things. Clients coming and going should be handled a different way rather than an event tick to see if someone joined.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

3 answers: sort voted first

In our latest main branch I've changed the functionality so that if a connection has no viewer (no PC or associated owning actor yet) it will not receive multicasts, whether reliable or not. The reasoning for this is:

  • Game code has no reasonable way to know if all clients have connected, and for a join in progress scenario has no way to send a multicast RPC to a select number of clients. Basically: game code cant work around this.

  • The RPC will almost never be able to be handled on the other end.

The fix is straight forward. I don't think it will be in 4.7 though. You will need to add it manually until then. ProcessRemoteFunction looks like this:

     // Multicast functions go to every client
             TArray<UNetConnection*> UniqueRealConnections;
             for (int32 i=0; i<ClientConnections.Num(); ++i)
                 Connection = ClientConnections[i];
                 if (Connection && Connection->Viewer)

(Adding the check to Connection && Connection->Viewer is what is important).

A side note!

You may want to rethink your approach if you are sending a multicast RPC in every tick. This sounds to me like you are replicating state via events. If you have some state that is constantly updating, you should replicate it via a replicated property and let the replication system handle sending it to everyone. RPCs should be used to replicate events. Properties should be used to replicate state.

more ▼

answered Jan 09 '15 at 03:17 PM

avatar image

Dave Ratti ♦♦ STAFF
206 6 6 7

avatar image Xanen Feb 04 '15 at 06:28 PM

Hi Dave- So is it safe to use reliable, multicast functions for actors that may go out of relevancy for some clients?
The following comment in IpNetDriver.cpp suggests otherwise: // Multicast reliables should probably never be used in gameplay code for actors that have relevancy checks.

What's the appropriate way to handle things that should behave as reliable if relevant? Think of an open world game where clients can come and go all the time. AI running on the server frequently needs to notify all clients to play various one-off anims (ie: a telegraph on an incoming attack from an AI).

I'm ok with reliable, multicasts getting dropped on the floor for clients who do not have the actor relevant. My concern is that this doesn't cause other bad behavior, such as the client disconnecting.

Thanks, -Josh

avatar image Dave Ratti ♦♦ STAFF Feb 06 '15 at 01:03 AM

In the AI example I would suggest that just be an unreliable message if the animations are short, or if they are long potentially replicated as state (properties), e.g, 'current animation + time started/left' since all you care about is the last played animation. This would also make it so if an actor suddenly became relevant then it would know what animation should be playing.

Reliable really implies the event is critical for the actor to function. It also implies ordering is important (if event A is dropped then event B may not be able to be handled properly).

avatar image KillerPenguin Jul 08 '15 at 03:12 AM

I don't get it, how do I tell my character to do something across the network, if I don't use Reliable NetMulticast then?

I have exactly what Dave said here -> "Reliable really implies the event is critical for the actor to function. It also implies ordering is important (if event A is dropped then event B may not be able to be handled properly)."

SO what then?

avatar image Dave Ratti ♦♦ STAFF Jul 09 '15 at 12:17 AM

If you have that exact scenario, then by all means use reliable multicast. I don't mean to say you never ever should use them, but the cases should rare in my experience.

The short answer is, usually if something is important it should probably be replicated as state (a replicated property). These are guaranteed to make it to clients and anyone who joins late will get the latest values.

Consider if you had events A -> B -> C, and all are critical and must be processed in order. You could replicate those events as reliable RPCs and the network layer will get them to everyone - everyone that is currently in the game and is relevant to those actors! If someone joins in progress between events A and B, he will never know about event A. If knowing about A was truly critical for the actor to work, then you are in trouble.

If you had those events A B C, ask why are they critical? If they are critical, they probably have side effects. Can you replicate those side effects directly instead? Say event A sets a bool that will influence how event B and C work (maybe if event X happens before B, then C acts differently). Instead of replicating A as an event, replicate the bool that A sets as a property. The example is primitive, but that is the point I was trying to make. Don't confuse critical with "important". When I mean critical I mean "the event does something that if everyone doesn't do it the actor will not be able to recover/function properly"

avatar image KillerPenguin Jul 09 '15 at 12:29 AM

Huh, you confused me even more. Does Reliable NetMulticast re-fire all those A-B events for those who join later?

Well, anyhow my problem is, there's a fatal error when clients try to rejoin a game with many NetMulticast firing. The game simply just crashes on occations. I tried switching to unreliable, and the problem still persist. I then tried pausing the game with new user's Prelogin() and unpause it afterward, but that doesn't help either.

Is there a better way to do this?

avatar image Dave Ratti ♦♦ STAFF Jul 09 '15 at 03:03 PM

Huh, you confused me even more. Does Reliable NetMulticast re-fire all those A-B events for those who join later?

Net multicast does NOT refire if people join later.

Without knowing more about your problem, if you think you have to fire multicasts nearly every frame, you should probably be using replicated properties instead.

You should post your crash in another thread and someone on the network team can fix it or figure out what is going on.

avatar image muchcharles Aug 30 '18 at 04:49 AM

Hi Dave,

I was linked here from this:


What I'm seeing is reliable multicasts get dropped when a client is paused in the debugger for 10-20 seconds or so, but not paused long enough to cause a client timeout with disconnect. Is that normal? I need the events to be reliable, and would rather a client get dropped than have gaps in the reliable multicast events.

avatar image muchcharles Aug 30 '18 at 05:52 AM

For anyone Googling broken reliable multicast and trying to decipher UE-24772, I've found the origin of the 1.5s timeout it refers to:

in int32 UNetDriver::ServerReplicateActors_PrepConnections:

         if ( OwningActor != NULL && Connection->State == USOCK_Open && ( Connection->Driver->Time - Connection->LastReceiveTime < 1.5f ) )
                     Connection->ViewTarget = NULL;

Once it sets Connection->ViewTarget to NULL, that's what breaks ProcessRemoteFunction.

A 1.5s timeout seems really short for this, if I'm reading this right, someone could get a burst of packet loss or have their machine hitch for that amount of time, and they would start losing reliable multicast packets?

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

Hey skeleton60,

I am sorry this post was not addressed earlier. I was able to reproduce this behavior in 4.5.1 and have entered a bug report for our developers (UE-4901). I will let you know when I see an update. Thanks for the report!

more ▼

answered Nov 01 '14 at 07:33 PM

avatar image Timbo Dec 25 '14 at 06:37 PM

Hi Ben Halliday,

how is the progress? There are similar issues with reliable multicasts in 4.6.1. https://answers.unrealengine.com/questions/67229/multicast-rpc-issue.html#answer-151595

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

I've been digging through the source with 4.6.1. Your main issue here is that you are calling a reliable multicast on the tick event. Multicasts are designed for non gameplay important events and should remain unreliable. When made reliable, the call to the client is "forced". If the reliable multicast rpc is called before the client is done logging in, because it is "forced", it thinks it is a broken or new instance of a previous connection.


 // on the server, if we receive bunch data for a channel that doesn't exist while we're still logging in,
 // it's either a broken client or a new instance of a previous connection,
 // so reject it
 else if ( PlayerController == NULL && Driver->ClientConnections.Contains( this ) )
     UE_LOG( LogNetTraffic, Error, TEXT( "UNetConnection::ReceivedPacket: Received non-control bunch during login process" ) );

I came up with a fix but requires editing the engine source.

change \Engine\Source\Runtime\Online\OnlineSubsystemUtils\Private\IpNetDriver.cpp at line 320 from

 if (IsRelevant)
     if (Connection->GetUChildConnection() != NULL)
         Connection = ((UChildConnection*)Connection)->Parent;
     InternalProcessRemoteFunction( Actor, SubObject, Connection, Function, Parameters, OutParms, Stack, bIsServer );


 if (IsRelevant && (Function->FunctionFlags & FUNC_NetReliable) ? Connection->OwningActor != NULL : true)
     if (Connection->GetUChildConnection() != NULL)
         Connection = ((UChildConnection*)Connection)->Parent;
     InternalProcessRemoteFunction( Actor, SubObject, Connection, Function, Parameters, OutParms, Stack, bIsServer );

Now, if the multicast is unreliable, it behave as before. But if it is reliable, it won't be called on the client until the Connections owning actor is not null. In this case, I believe that the owning actor needs to be a player controller or else the connection will still be closed.

Another option that doesn't involve changing the source code is to not use reliable multicasts until after all clients have connected to the host. If that is not an option, use reliable multicasts sparingly and it should be a very rare occasion that the connection is dropped when the client tries to join.

more ▼

answered Dec 29 '14 at 12:01 AM

avatar image

822 38 39 241

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question