LOG: bluebox.v3.BlueBox: Invalid request, session expired.

Post here your questions about SFS2X. Here we discuss all server-side matters. For client API questions see the dedicated forums.

Moderators: Lapo, Bax

SomeTallGy
Posts: 3
Joined: 08 Oct 2014, 20:33

LOG: bluebox.v3.BlueBox: Invalid request, session expired.

Postby SomeTallGy » 26 Feb 2015, 22:36

Hi folks, this message is filling up my logs on my production server and I am having a tough time figuring out why.

Class: bluebox.v3.BlueBox
Message: Invalid request, session expired. Message: { ssid: eadeccab136309a4d4e8ba9a5d2dfba2, cmd: data, data: 56 bytes�}

(Screenshot admin log attached)

I am running 2.9.2 on a Amazon EC2 Linux Instance.
Clients connected are Web AS3 Flash clients

I have anywhere from 1-2k CCU and no other error messages or warnings.

It's not that it's breaking our server, but it's certainly spooling out very large log files.

Your help is appreciated!
Attachments
logFile.jpg
Log Screenshot
(232.57 KiB) Not downloaded yet
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: LOG: bluebox.v3.BlueBox: Invalid request, session expire

Postby Lapo » 27 Feb 2015, 09:40

Hi,
the message usually indicates that a client is either no longer connected or its session is not recognized.

From what I can see in the screenshot the requests are all sent by the same client (same session id) and they are sent at a very high rate (some arrived in the same millisecond).
Does your application send very fast messages? Is it like a real time game?

If not this would raise a red flag, as it may look as a hacking attempt.

Let us know.

Cheers
Lapo
--
gotoAndPlay()
...addicted to flash games
SomeTallGy
Posts: 3
Joined: 08 Oct 2014, 20:33

Re: LOG: bluebox.v3.BlueBox: Invalid request, session expire

Postby SomeTallGy » 27 Feb 2015, 19:01

Hi Lapo, thank you for getting back so fast.

Yes the server sends messages at a high rate at 10 per second to each client connected in a game room. I am also receiving messages at 10 per second from clients to the server. I mused our code off of the space race example, so it's a similar structure.

So yes, it appears that connected clients are creating these warnings at a high rate.

Another clue is that this has shown itself to happen even when the server is empty while I was running the 2.9.0 version. It would happen every couple seconds after a fresh restart. After patching to 2.9.2 I can't be certain this is still happening - but due to the 2.9.2 bluebox fixes mentioned, i figured updating would solve the issue - at least partially.

The first time I started noticing this happening was in mid development after updating my remote extension during development, while on 2.9.0. But the problem seem to persist into 2.9.2.
Could it be something code based?

Thanks for your input.

EDIT: Updated information about versions.
SomeTallGy
Posts: 3
Joined: 08 Oct 2014, 20:33

Re: LOG: bluebox.v3.BlueBox: Invalid request, session expire

Postby SomeTallGy » 28 Feb 2015, 22:12

Lapo - Attached is a log 5 minutes after opening the gates into the server (ERROR mode only). I was watching the logs and it seems that it leads more evidence to your suggestion. It appears a user would generate a string of these, then get disconnected. Then another user, and another. This was generated after the server populated up to about 1200 or so CCU.
Attachments
SFS2X_RuntimeLog_backup_20150228_210735.zip
(20 KiB) Downloaded 268 times
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: LOG: bluebox.v3.BlueBox: Invalid request, session expire

Postby Lapo » 02 Mar 2015, 11:54

Of those 1200 CCU how many are connected via BlueBox? You can check this in the AdminTool's Dashboard, bottom right corner, there's a table with all the connection stats.
It tells you how many clients are connected via socket, how many via HTTP.

I would expect the vast majority of those 1200 CCU to be connected via socket. (at least 90% socket)

The rate of the messages in your log file is pretty high, almost 8-9 msg/second. It correlates with the message rate you're using in your application. At that rate a portion of the HTTP-based clients will certainly fail to keep up, because HTTP is much slower.

Leaving aside the hacking hypothesis there could be two other options:

1) The client is not handling the disconnection event properly and keeps sending requests after having been disconnected.
2) There is a temporary "grey-area" between the server side and client side disconnection in which the client still doesn't know about the lost connection and keeps sending data. Given the high rate of messages and the slowness of HTTP this is a possibility.

hope it helps
Lapo

--

gotoAndPlay()

...addicted to flash games

Return to “SFS2X Questions”

Who is online

Users browsing this forum: No registered users and 64 guests