By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post

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!

Topics
Game Tech
Tags
Amazon GameLift
Language
English
rePost-User-1960859
asked 2 years ago243 views
9 Answers
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!

rePost-User-1960859
answered 2 years ago
  • rePost-User-4427887
    a year ago

    I have encountered this issue as well, but I need to use the secured connection (cert) for a webgl https build, have you figured out how to fix it?

  • Rick
    6 months ago

    Was there ever a resolution to this? I am having exactly the same problem and not sure how to resolve this issue with not receiving messages when using a fleet with a TLS certificate.

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
rePost-User-7108006
answered 2 years 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

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

  3. 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:

rePost-User-1960859
answered 2 years ago
0

any thoughts on this? still having this issue @REDACTEDUSER

rePost-User-1960859
answered 2 years ago
0

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

#P61454798

rePost-User-7108006
answered 2 years ago
0

Hey @REDACTEDUSER

rePost-User-7791211
answered 2 years 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.

rePost-User-7791211
answered 2 years 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.

rePost-User-1960859
answered 2 years 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.

rePost-User-7791211
answered 2 years 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

Relevant content