By using AWS re:Post, you agree to the Terms of Use
/Client not receiving RTS message/

Client not receiving RTS message

0

I'm having trouble with one particular piece of code that is supposed to be sending a message to a client. Both pieces of code below are from my Realtime Server Script:

function onPlayerAccepted(player) {
    logger.info("..New player accepted: " + player.peerId);
    const newPlayerMessage = session.newTextGameMessage(OP_CODE_PLAYER_ACCEPTED,
        session.getServerId(),
        JSON.stringify(galaxyAndLocalPlayerState));
    session.sendReliableMessage(newPlayerMessage, player.peerId);
}

The above block within my realtime server script runs when a player is accepted, and the message is successfully received by the client (Unity). On the client side, logs show that OnDataReceived() is called.

RTS Logs for above call: 02 Mar 2022 03:59:32,191 [INFO] (ManhuntServerScript.js) 96: ..New player accepted: 1 02 Mar 2022 03:59:32,191 [INFO] (index.js) 333: Received custom game message from sender: -1 with opCode: 100, targetPeerId: 1, targetGroupId: 0

function onMessage(gameMessage) {
      switch (gameMessage.opCode) {
          case OP_CODE_TRAVEL_REQUEST:
              logger.info("..Travel Request Received from Peer " + gameMessage.sender + " to PlanetId: " + gameMessage.getPayloadAsText());
              const travelResponseMessage = session.newTextGameMessage(OP_CODE_TRAVEL_BEGIN,
                  session.getServerId(),
                  JSON.stringify(playerStates));

              session.sendReliableMessage(travelResponseMessage, gameMessage.sender);
              break;

          default:
              logger.info("..Unrecognized Op Code received: " + gameMessage.opCode);
              break;
      }
}

The above block shows the message is being sent in the server logs, but is not received by the Unity client. I have ensured the op codes match. On the client side, logs show that OnDataReceived() is NOT called.

RTS logs for above call: 02 Mar 2022 03:59:36,628 [INFO] (index.js) 333: Received custom game message from sender: 1 with opCode: 200, targetPeerId: -1, targetGroupId: 0 02 Mar 2022 03:59:36,628 [INFO] (ManhuntServerScript.js) 136: ..Travel Request Received from Peer 1 to PlanetId: 2 02 Mar 2022 03:59:36,629 [INFO] (index.js) 333: Received custom game message from sender: -1 with opCode: 102, targetPeerId: 1, targetGroupId: 0


The only thing I can think of is that possibly a realtime server can't send a message within onMessage() but that seems silly to me.

Thanks in advance for any insight!

asked 4 months ago0 views
9 Answers
0

Hi @REDACTEDUSER

This is very strange indeed :P

It's not a network/firewall issue because your client could receive some message, and from the logs, looks like your server has succeeded in sending to playerId 1 during onPlayerAccepted, but not during onMessage. (Yes, you can send messages during onMessage)

I'd try a these things, and do them in both onPlayerAccepted and onMessage to compare results:

  1. Before sending the message in onMessage(), print out all connected players, i.e. session.getPlayers().forEach((player, playerId) => ...). Could it be possible that the player disconnected between the 2 sendReliableMessage calls?
  2. Try broadcasting to the group instead. session.sendReliableGroupMessage(...), see: https://docs.aws.amazon.com/gamelift/latest/developerguide/realtime-script-objects.html, trying using -1 as the group id to broadcast to ALL players
  3. (Shot in the dark) Try using UDP instead of TCP? i.e. session.sendMessage(...) (the args is identical to sendReliableMessage
answered 4 months ago
0

Thanks for your reply! Here is a quick update:

  1. I tried this and can confirm that playerId 1 is still connected from the following log:

04 Mar 2022 00:56:47,762 [INFO] (index.js) 191: Message received from player 1 04 Mar 2022 00:56:47,763 [INFO] (index.js) 196: Packet (including both internal messages and custom game messages) received from player: 1 04 Mar 2022 00:56:47,763 [INFO] (index.js) 333: Received custom game message from sender: 1 with opCode: 200, targetPeerId: -1, targetGroupId: 0 04 Mar 2022 00:56:47,763 [INFO] (ManhuntServerScript.js) 137: ..Travel Request Received from Peer 1 to PlanetId: 2 04 Mar 2022 00:56:47,763 [INFO] (ManhuntServerScript.js) 144: Connected player: playerId: 1 04 Mar 2022 00:56:47,763 [INFO] (index.js) 333: Received custom game message from sender: -1 with opCode: 102, targetPeerId: 1, targetGroupId: 0

  1. I gave this a try and it did not work

  2. This unfortunately did not seem to change anything either

I have some more info that might help: I tried a couple things on the client side, client.Session.State says READY whenever i check. However there is one thing that seems to be off.. after 2 minutes of connectivity the connection always closes with the following log (Unity side):

[server-sent] OnErrorEvent - Sender: -2 OpCode: -101 [server-sent] OnCloseEvent

I have not defined a -101 opcode and am not sure what -2 could mean for sender. It always happens exactly 2 minutes after opening the connection. Am I missing a step here?

Thanks again :slight_smile:

answered 4 months ago
0

any thoughts on this? still having this issue @REDACTEDUSER

answered 4 months ago
0

I have sent this issue to the GameLift team to investigate, sorry for the late reply!

#P61454798

answered 4 months ago
0

Hey @REDACTEDUSER

answered 4 months ago
0

-101 is the opCode corresponding to PLAYER_CONNECT_OP_CODE which is defined in the GameLift RTS Client SDK.

In this case my suspicion is there's an issue with the Websocket Connection, which surfaces as this error. Is there anyway to identify or add additional logging on the client side which might help surface connection related issues? Once you provide the GameSessionId I can take a look at the GameLift server end of things to see if there's anything I can identify on our end.

answered 4 months ago
0

I'll work on that client side logging. Also, I am not seeing any reference to opCode -101 in the client SDK documentation. Am I looking in the right place?

Here is a game session where this has happened: Game session: arn:******

Thanks for looking into this!

edit: I'm digging into wireshark and can see that one of the incoming packets from my instance's IP has the TCP "Reset" flag set. my knowledge here is limited but i figured this might help:

Source Port: 1900 Destination Port: 65287

Flags: 0x004 (RST) .... .... .1.. = Reset: Set


edit 2: I changed my server loggingLevel to debug and found the following logs from this game session: arn:******

19 Mar 2022 19:19:07,332 [INFO] (ManhuntServerScript.js) 170: Tick... 23 activePlayers: 1
19 Mar 2022 19:19:08,333 [INFO] (ManhuntServerScript.js) 170: Tick... 24 activePlayers: 1
19 Mar 2022 19:19:08,782 [DEBUG] (index.js) 130: Attempting to ping all (1) connected players in the server
19 Mar 2022 19:19:08,782 [DEBUG] (ws.js) 211: Sent ping to player: 1
19 Mar 2022 19:19:09,334 [INFO] (ManhuntServerScript.js) 170: Tick... 25 activePlayers: 1
19 Mar 2022 19:19:10,335 [INFO] (ManhuntServerScript.js) 170: Tick... 26 activePlayers: 1
19 Mar 2022 19:19:11,337 [INFO] (ManhuntServerScript.js) 170: Tick... 27 activePlayers: 1
19 Mar 2022 19:19:12,338 [INFO] (ManhuntServerScript.js) 170: Tick... 28 activePlayers: 1
19 Mar 2022 19:19:13,338 [INFO] (ManhuntServerScript.js) 170: Tick... 29 activePlayers: 1
19 Mar 2022 19:19:14,340 [INFO] (ManhuntServerScript.js) 170: Tick... 30 activePlayers: 1
19 Mar 2022 19:19:15,341 [INFO] (ManhuntServerScript.js) 170: Tick... 31 activePlayers: 1
19 Mar 2022 19:19:16,343 [INFO] (ManhuntServerScript.js) 170: Tick... 32 activePlayers: 1
19 Mar 2022 19:19:17,344 [INFO] (ManhuntServerScript.js) 170: Tick... 33 activePlayers: 1
19 Mar 2022 19:19:18,346 [INFO] (ManhuntServerScript.js) 170: Tick... 34 activePlayers: 1
19 Mar 2022 19:19:19,347 [INFO] (ManhuntServerScript.js) 170: Tick... 35 activePlayers: 1
19 Mar 2022 19:19:20,349 [INFO] (ManhuntServerScript.js) 170: Tick... 36 activePlayers: 1
19 Mar 2022 19:19:21,350 [INFO] (ManhuntServerScript.js) 170: Tick... 37 activePlayers: 1
19 Mar 2022 19:19:22,352 [INFO] (ManhuntServerScript.js) 170: Tick... 38 activePlayers: 1
19 Mar 2022 19:19:23,353 [INFO] (ManhuntServerScript.js) 170: Tick... 39 activePlayers: 1
19 Mar 2022 19:19:24,354 [INFO] (ManhuntServerScript.js) 170: Tick... 40 activePlayers: 1
19 Mar 2022 19:19:25,356 [INFO] (ManhuntServerScript.js) 170: Tick... 41 activePlayers: 1
19 Mar 2022 19:19:26,357 [INFO] (ManhuntServerScript.js) 170: Tick... 42 activePlayers: 1
19 Mar 2022 19:19:27,359 [INFO] (ManhuntServerScript.js) 170: Tick... 43 activePlayers: 1
19 Mar 2022 19:19:28,360 [INFO] (ManhuntServerScript.js) 170: Tick... 44 activePlayers: 1
19 Mar 2022 19:19:29,361 [INFO] (ManhuntServerScript.js) 170: Tick... 45 activePlayers: 1
19 Mar 2022 19:19:30,363 [INFO] (ManhuntServerScript.js) 170: Tick... 46 activePlayers: 1
19 Mar 2022 19:19:31,364 [INFO] (ManhuntServerScript.js) 170: Tick... 47 activePlayers: 1
19 Mar 2022 19:19:32,365 [INFO] (ManhuntServerScript.js) 170: Tick... 48 activePlayers: 1
19 Mar 2022 19:19:33,367 [INFO] (ManhuntServerScript.js) 170: Tick... 49 activePlayers: 1
19 Mar 2022 19:19:34,368 [INFO] (ManhuntServerScript.js) 170: Tick... 50 activePlayers: 1
19 Mar 2022 19:19:35,369 [INFO] (ManhuntServerScript.js) 170: Tick... 51 activePlayers: 1
19 Mar 2022 19:19:36,371 [INFO] (ManhuntServerScript.js) 170: Tick... 52 activePlayers: 1
19 Mar 2022 19:19:37,372 [INFO] (ManhuntServerScript.js) 170: Tick... 53 activePlayers: 1
19 Mar 2022 19:19:38,373 [INFO] (ManhuntServerScript.js) 170: Tick... 54 activePlayers: 1
19 Mar 2022 19:19:38,782 [DEBUG] (index.js) 130: Attempting to ping all (1) connected players in the server
19 Mar 2022 19:19:38,783 [WARN] (index.js) 133: Player 1 did not respond to the last ping. Terminating the player client.
19 Mar 2022 19:19:38,783 [INFO] (ws.js) 206: TCP client connection for player: 1 is terminated by the server
19 Mar 2022 19:19:38,784 [DEBUG] (ws.js) 155: Received 'close' event from websocket client: undefined, player: 1 from ::ffff:(MY-IP-ADDRESS):61386

edit 3: From my server script I made the following change:

const configuration = {
    pingIntervalTime: 30000
};

to

const configuration = {
};

resulting in the player session moving to completed a few seconds after the connection is made. It looks like the client could respond to the first ping but not the second. I looked at this sample project and found the same configuration constant.

answered 4 months ago
0

Thanks for providing that information @REDACTEDUSER

I've gone over logs on our end and from the Game Server's view there is nothing that stands out to me. Like you've discovered via server logging the RTS server is trying a routine ping to the client, and the client doesn't respond. As a result the server terminates the player connection. I wonder if the TCP "Reset" flag is set when the server terminates the connection (Could you check if the timestamps align?).

Given that the client can initially receive a message from the server, I'm wondering if this could be something network or firewall related? A couple more things we can potentially try to narrow down the issue:

  1. Can we attempt running the client on a different network to see if the behavior is the same? This will help isolate if this is something network or client related.
  2. Have you tried running the RTS sample to see if everything works as expected? This is a tested sample, so I would expect this would help narrow down issues with the environment the client is running on.
  3. Are you running the latest version of the Client SDK?

With respect to the opCode I was viewing the code from the RTS Client SDK itself.

answered 3 months ago
0

Thanks for the response. I actually just found the solution, it was a problem with my client not getting the certificate generated from the RTS. When I set the RTS to not generate a certificate, the connection and messages work as intended. Here are my new questions:

  1. Why is my client able to connect to my RTS (and receive an onPlayerAccepted message) without the fleet's generated cert in the first place? This seems like a security issue to me.

  2. Is there any documentation on best practices for a client to obtain a certificate for a fleet? I don't want clients to have to make AWS API calls using temporary credentials, which is the only way I have seen so far. I'm guessing this will be a lambda similar to how the recommended matchmaking flow works?

Thanks again!

answered 3 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions