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 Disconnect after Rejoining Session with Steam

Note that this is only an issue when using the Steam online subsystem.

After successfully connecting to a session, disconnecting, and rejoining that same server, the client will be connected for about 10 seconds before disconnecting, saying it simply lost connection to the server. Other players connected to the server are unaffected, and this only happens after the client has already disconnected from that server.

It happens almost every time, and I've successfully recreated it in a clean project. Additionally, this happens whether or not using the blueprint nodes or manually via C++ and interacting with the session interface.

Steps to reproduce (in blueprint, for simplicity):

  1. Client A creates a new server via the Create Session BP node, traveling to the map once Create Session was successful.

  2. Client B Searches, finds, and joins the above server, loading the map and joining. The client can play as long as it can with no issues.

  3. Client B disconnects via DestroySession node and returning to a menu state.

  4. Client B Immediately performs Step 2 and reconnects to the server.

  5. Client B is connected, spawned, and visible to everyone for about 10 seconds

  6. Client B loses connection to the server, with no further information given.

If 6 does not happen, it almost always will happen by the third or fourth rejoin. I tried looking into the steam subsystem's source if it was an issue with authenticating via steam, but I couldn't find anything, only that, according to the logs, the server mysteriously decides to close their connection, resulting in the disconnect.

I'd also like to add that we've had this issue for as long as we can remember (at least since 4.7), but assumed it was simply us misusing sessions.

In a simplified test project, these are the log outputs with LogNet and LogOnline set to Verbose Note that in this example, it happened upon the first reconnect of the Client.

Server http://pastebin.com/mdAXaWxz

Client http://pastebin.com/XSZ5F1SQ

If you need the test project, I can provide it if necessary. This is a crucial issue as our game relies heavily upon steam and steam sessions.

Product Version: UE 4.10
more ▼

asked Nov 22 '15 at 12:57 AM in Bug Reports

avatar image

49 3 4 10

avatar image Crzyhomer STAFF Nov 23 '15 at 03:54 PM

My initial guess is some bad interaction within the p2p socket code that is trying to cleanup your previous disconnection.

Adding some more logging in bool FSocketSubsystemSteam::Tick(float DeltaTime) might help identify the issue.

The code relies on the socket receiving data so that P2PTouch can be called an keep the connection alive. When a player logs out, they get added to the DeadConnections list and eventually removed. While in that list, new connections from that player shouldn't be accepted in AcceptP2PConnection. P2PRemove might be trying to clean up the new connection based on the existence of the old. Figuring out the order of operations here would be helpful.

When you reconnect quickly, do you see them in the DeadConnections list? Have they been completely cleaned up by then (ie has the server completely removed all traces of this player)?

If you take a much longer period of time to reconnect, it sounds like this problem isn't there? Or did I misread?

It's possible that the lower level Steam p2p API is having trouble, but let's see what more logging in the engine will reveal.

avatar image Foohy Nov 23 '15 at 09:12 PM

I inserted some log prints at the top of that tick, and it appears AcceptedConnections and DeadConnections are behaving as they should. By the time the second client reconnects, their connection is gone from DeadConnections.

Something interesting I found, was inserting a breakpoint at P2PRemove just before the client is forcefully disconnected, reveals that it might be that UNetConnection getting garbage collected: Call Stack

Could this be the previously dead connection being GC'd, but because it's the same client it's disconnecting their new connection?

And to answer your question for if the client waits to rejoin, so far in my tests it appears that yeah, if they wait before rejoining (like 2 minutes or so), they can successfully remain on the server without issue. How long they wait is just entirely dependent on how long until the GC runs (assuming that's what's happening).

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

2 answers: sort voted first

Alright I think I've managed to fix this, but I'll post here just to make sure there aren't any unintended side effects.

In the steam socket code, USteamNetConnection overrides the CleanUp() method and calls the relevant function for unregistering and removing the steam P2P connection.

The problem, is that this is called twice; by both NetworkDriver's TickDispatch when it's found to be a straggling connection, but also when that USteamNetConnection is garbage collected. By the time the user rejoins it's about the time that object is garbage collected, and will destroy the same user's steam P2P connection.

So naturally, a simple fix I found was to simply ensure the steam cleanup code was called exactly once: (SteamNetConnection.cpp)

 void USteamNetConnection::CleanUp()

     /* Insert new code here */
     //Only unregister the steam socket if it's the first time we've been told to CleanUp
     if (bAlreadyCleaned) return;
     bAlreadyCleaned = true;
     /* End new code */

     if (!bIsPassthrough)

So far in my testing, this has fixed all issues, and still appear to be properly removing connections, but I've not done more extensive/thorough tests. Will this hold up in the long term, would this be a proper fix?

more ▼

answered Nov 24 '15 at 08:15 AM

avatar image

49 3 4 10

avatar image Tomble38 Nov 29 '15 at 11:01 AM

Do you think there is a fix for this without messing with C++ ? Because I have the same Issue in a BP-only project. I mean I could get into the code, but I'd rather stick with BP's (also to see to what extend they can be used)

avatar image Ben Halliday STAFF Dec 03 '15 at 08:40 PM

Hi Foohy and ooParanoia,

Josh M is out of the office, but I'd like to get a report in for his return. Unfortunately, I can't reproduce this in a test project, following the instructions above. Foohy, you mentioned you'd be able to share the test project. If you still have that or wouldn't mind creating another for us, could you zip it up and upload it somewhere and get me a download link? I'd really appreciate it. Thanks!

avatar image Foohy Dec 03 '15 at 10:39 PM

Yep I've still got it, I've gone ahead and changed the appid to spacewar '480'.

Additionally, the test project is incredibly bare bones -- When joining someone, I've not bothered to do any proper replication on actors and characters. The 'server' state is a specific map, and they're then returned to a 'menu' map when they're disconnected.



avatar image Ben Halliday STAFF Dec 08 '15 at 06:28 PM

Thanks! I've created UE-24229 and included your project as an example. I'm still not able to reproduce in a new project, but I can in yours. I suspect there's something I'm missing, but this should help Josh M locate the source of the issue. If he has anything to add about your suggested fix or any other information, we'll post an update here. Thanks again!

avatar image Ben Halliday STAFF Dec 15 '15 at 08:46 PM

As a heads up: this has been fixed in our internal branch, and should be included in a future release version of the engine. If you need the GitHub link for the source change before that, let me know and I'll post it here.

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

Hello Foohy and ooParanoia,

Since Josh has been out and we've gotten some other users reporting the same problem, I went ahead and took a look. You all are right about the problem, and your fix will work, although I've decided to fix it a slightly different way. I changed FSocketSubsystemSteam::UnregisterConnection to be the following:

 void FSocketSubsystemSteam::UnregisterConnection(USteamNetConnection* Connection)
     FWeakObjectPtr ObjectPtr = Connection;
     int32 NumRemoved = SteamConnections.RemoveSingleSwap(ObjectPtr);
     // Don't call P2PRemove again if we didn't actually remove a connection. This 
     // will get called twice - once the connection is closed and when the connection
     // is garbage collected. It's possible that the player who left rejoined before garbage
     // collection runs (their connection object will be different), so P2PRemove would kick
     // them from the session when it shouldn't.
     if (NumRemoved > 0 && Connection->RemoteAddr.IsValid())
         FInternetAddrSteam& SteamAddr = (FInternetAddrSteam&)(*Connection->RemoteAddr);
         P2PRemove(SteamAddr.SteamId, SteamAddr.SteamChannel);

Like I said, your fix is totally fine as well, but I prefer this one just because it avoids adding some redundant state to the USteamNetConnection object.

If you decide to give my fix a shot and you run into any issues with it, please post again here. This should make it into 4.11.

Thanks again for all your research into this issue!

more ▼

answered Dec 11 '15 at 04:11 PM

avatar image

Bart Bressler STAFF
51 1 3 6

avatar image erebel55 Jan 15 '16 at 10:58 PM

Is this still going to make it into 4.11?

avatar image Ben Halliday STAFF Jan 18 '16 at 08:35 PM

Hi erebel55,

I believe this fix was included in the 4.11 branch, and you should be able to see it in the 4.11 Preview 2 now if you'd like to test it out.

avatar image Syrill Feb 26 '16 at 05:49 PM

Is there any chance, that this might cause my problems with steam as well?

I don´t think so, as I already implemented your fix. However, I can´t find another possible root of the problem...

(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