That depends on how players will get matched and ultimately connect to your server. If you use our lobby-based matchmaking facilities, the sequence will go roughly like this:

1. Players make a FIND_OR_CREATE_LOBBY call to the LobbyService.
2. The lobby matchmaking process runs and a bunch of players get associated with a lobby instance.
3. Once the launch conditions are satisfied, brainCloud will launch an instance of your dedicated server.
4. The dedicated server will start and immediately make an S2S call to ask brainCloud for all the lobby instance details. These details will include each players name.

If you don't use lobby matchmaking, you'll need to use the S2S api to query brainCloud for the player details manually.

Just popping in to clarify @Paul-Winterhalder 's comment about catching the ROOM_ASSIGNED event...

That's actually not the event that should be listened for. That event is only sent if the lobby type has been configured with an associated server type and we've made a request to launch a server instance.

If no server type has been associated with the lobby type, the developer should listen and react to the STARTING event. That will be the event sent out just prior to the lobby being disbanded (assuming "Disband on start" has been selected).

So I took a look at a sample of 4 room server launches and I do see the 30 sec delay that you're referring to. I believe, however, that this isn't an issue with server launches taking too long... I believe the issue is that your lobby config is setup with an early launch window of 30 secs.

What the early launch window setting controls is at what point the "early" launch window opens. The early launch window is the 1st time that the matchmaking service will consider it appropriate to launch a server/container for the lobby members.

So what this means in your case is that the matchmaking service will NOT launch a server/container for the lobby instance until AT LEAST 30 secs has passed, regardless of whether or not the lobby members meet the launch criteria sooner than that (i.e. one of the members has set their "ready" status to true).

If you want to speed this up, I think you should look at reducing your early launch window setting.

Let me know if that makes sense or if I'm not understanding the issue correctly.

Thanks!

Hey @Alessio-Falsetti . Let me take a look and see if I can figure out what's going on.

Great @Alessio-Falsetti Glad to hear it!

Ok @Alessio-Falsetti ,
I'm 99% sure I know what's going wrong. Correct me if I'm wrong but your lobby type configuration has both "Disband on start" and "Allow join in progress" set to true.
This was a bug in our portal that existed up until the recent 5.2 release. Now, you cannot set both those values to true. The portal (neither portal-X nor the legacy portal) will not allow you to do this.
All that said, your lobby type configuration was obviously created before we fixed this so your lobby configuration is in a bad state and you need to choose one or the other.
I don't know enough about your use-case to say which you should choose but if you want to ask for some guidance, let us know and we can take a closer look at your requirements and figure it out.
For now, you can just do a quick test by turning one of "Disband on start" or "Allow join in progress" off and re-run your test.
Let us know how it turns out!

@Alessio-Falsetti Next question... what are your "Disband on start" and "Allow join in progress" settings for this lobby type?

Ok thanks @Alessio-Falsetti . We're still looking into it so I'll let you know when we have an update.

I'm assuming from your statement "if I try to rejoin the room" that you've connected successfully initially.

So a question for you... are you able to connect initially and it's failing on the reconnect? Or are you failing to connect at all?

Hmm... Let me poke around.

Hey @Alessio-Falsetti . In order to enable that feature, you need to update the "Custom Environment" settings for the appropriate "My Servers" definition:

Also Alessio, can you confirm whether your lobby type has the "Allow join in progress" Rule enabled or disabled? That's also relevant. Thanks!

I'll let Paul speak to the performance issues that you mention as concerns. I think your right to be concerned about that performance so I'll let Paul chime in.

Great to hear Alessio. Let us know if anything else pops up or if you notice any other gaps. Ciao!

Notice that the "_public" settings key/value is returned as a "publicSettings" key/value in the response to GET_LOBBY_INSTANCES. Is that something that you can take advantage of for your use-case?

Hey Alessio. I just thought of something that might help you with part of your use-case. We do have the facility for you to attach some arbitrary data to a lobby instance that WILL be returned in the GET_LOBBY_INSTANCES
call. That piece of data is set by specifying a "_public" key in the lobby instance "settings" field. For example, here's a sample call to create a lobby instance that sets it:

CREATE_LOBBY REQUEST:

{
   "service": "lobby",
   "operation": "CREATE_LOBBY",
   "data": {
      "lobbyType": "TestPVP",
      "rating": 76,
      "otherUserCxIds": [],
      "settings": {
         "_public": {
            "hello": "world"
         }
      },
      "isReady": false,
      "extraJson": {},
      "teamCode": "all"
}
}

CREATE_LOBBY RESPONSE:

{
   "status": 200,
   "data": {
      "lobbyId": "23713:TestPVP:41"
   }
}

GET_LOBBY_INSTANCES REQUEST:

{
   "service": "lobby",
   "operation": "GET_LOBBY_INSTANCES",
   "data": {
      "lobbyType": "TestPVP",
      "criteriaJson": {
         "rating": {
            "min": 25,
            "max": 99
         }
      }
   }
}

GET_LOBBY_INSTANCES RESPONSE:

{
   "status": 200,
   "data": {
      "lobbiesByRating": {
         "76.0": [{
            "id": "23713:TestPVP:41",
            "lobbyType": "TestPVP",
            "state": "early",
            "rating": 76,
            "desc": "TestPVP",
            "owner": {
               "profileId": "c14caf2b-6c72-4c8e-9280-54356f7d56c2",
               "name": "",
               "rating": 0,
               "cxId": "23713:c14caf2b-6c72-4c8e-9280-54356f7d56c2:nscnrabmi1ukk1ncr2dqpf9nau"
            },
            "numMembers": 1,
            "maxMembers": 2,
            "publicSettings": {
               "hello": "world"
            }
         }]
      }
   },
}

Thanks for the additional details Alessio. Paul and I will discuss some options and get back to you.

Could we get some elaboration on your use-case Alessio? For example, what's your definition of "currently connected users"? Are these users just generally online or actually members of the lobby instance itself? Something else that may or may not be relevant: how are these lobbies being created? Manually via the client/CloudCode ... or via our built-in matchmaking processes? Thanks!