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

What conditions cause IoT to create a new "sessionIdentifier" for a device connection?

0

I'm trying to diagnose an issue I have for my chat app that happens under the following conditions:

  • I use persistent sessions (mqtt feature), and all topics are automatically resubscribed properly during regular disconnects/reconnects etc (works great).
  • When a connection terminates for an extended period of time, e.g. I close my laptop and go to sleep at night, and then wake up and open my laptop hours later in the morning, the client properly reconnects, however aws has now assigned a new "sessionIdentifier" for the connection.
  • mqtt client_id is the same as day before and has not changed.
  • The client no longer receives any events as I believe it has lost all previously subscribed topics from day before, from the previous persistent session.

This is a major issue for me because:

  • My application wakes up and connects to mqtt and appears connected etc, but is completely non-functional as it is no longer subscribed to any topics (on aws iot side, my assumption).
  • I use "sessionIdentifier" as a critical attribute to track my own application session state, and now that it has changed my app state is off.
  • Somewhat tangentially related to a different question I recently asked on here about how to access sessionIdentifier value in non-reserved aws topics, because right now since I can't access it outside non-reserved topic, and there is no lifecycle event for ping response, I had to build a mechanism where my lambda connected to aws lifecycle events sends the session id ("sessionIdentifier") back to the client immediately on "connected" events. Since the sessionIdentifier has changed and I believe all subscriptions wiped with it, the client does not receive the new session id.

So my question is why is aws creating a new "sessionIdentifier" when reconnecting after hours asleep, despite that the mqtt client id has not changed, and despite that the value remains constant throughout otherwise regular connect/disconnect lifecycle events?

Am I correct in my assumption that this is why my client is no longer subscribed/receiving events despite being connected?

Please advise on any steps to mitigate this. It would be VERY helpful to have aws reuse the previous sessionIdentifier and not create a new one if this is indeed the issue.

Topics
Internet of Things (IoT)
Tags
AWS IoT Core
Language
English
borg
asked a year ago527 views
2 Answers
1
Accepted Answer

Hey.

It sounds like your Persistent session has expired. The default session time is one hour so unless you have changed that, this is the reason you don't get the messages after a long disconnect. As per documentation: "If a client doesn't reconnect to its persistent session before it expires, the session ends and its stored messages are discarded. " https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions

Changing the session time should solve your problem.

profile picture
EXPERT
JimmyDqv
answered a year ago
  • borg
    a year ago

    Hey thanks, yeah sounds like that's the issue! However in the linked doc I don't see anything about how to change the value of the persistent session expiration. The only thing I see it mentioning is that the default is one hour. Is there a way to configure it to be longer or even indefinite? Where is this configured? I don't see that as a client-side connection property (mqtt.js docs)

    "In MQTT 3, the default value of persistent sessions expiration time is an hour, and this applies to all the sessions in the account."

  • borg
    a year ago

    ok nvm found the page to request an increase. Only thing is it still has the same problem hypothetically even at the max of 7 days. Ideally I could store it indefinitely, but I'm thinking maybe I need a mechanism on the client to somehow detect if upon reconnect it is a new persistent session. It'd be nice if that sessionIdentifier were somehow transferred to the client upon connection e.g. via connect event.

1

AWS IoT assigns a unique session identifier to each client connection. This identifier is generated at the beginning of a new MQTT session, and it remains the same throughout the lifecycle of that session.

You have mentioned that your application is not receiving events after waking up from sleep and re-establishing the connection. This might happen because the session has been considered "expired" on AWS IoT end. When a new connection request comes in, AWS IoT sees it as a new session, thus assigns a new session identifier. The old session with all its subscriptions is discarded and thus your application no longer receives messages for those topics.

AWS IoT supports the MQTT protocol, which includes the notion of persistent sessions (also called "clean sessions" in MQTT terminology). When a client connects to AWS IoT using MQTT, it can specify the cleanSession flag in the CONNECT message.

  • If cleanSession=true, the session lasts as long as the network connection. When the client disconnects, AWS IoT does not store any session data.
  • If cleanSession=false, the session is persistent. The session stays alive for a period of time after the network connection is closed. AWS IoT stores the session data, which includes subscriptions and unacknowledged messages.

In AWS IoT, the session expiration period is not configurable and the duration is not publicly documented, but it's not infinite. If the connection is closed and remains closed for a prolonged period of time, AWS IoT may decide to close the session. It seems like this is what is happening in your case when the application sleeps overnight.

To mitigate this, consider the following:

  • Resubscribe after reconnecting: Update your application to resubscribe to the necessary topics each time it reconnects to AWS IoT. This ensures that the application continues to receive messages even if the session was closed and a new session was started.
  • Keep-alive Messages: MQTT has a keep-alive mechanism where the client sends PINGREQ messages to keep the connection alive. Adjust your keep-alive interval to ensure the session is not closed due to inactivity.
  • Session State Management: If you're relying on the sessionIdentifier for maintaining state in your application, consider managing the state within your application instead.

Remember to review your MQTT client settings and ensure you have correctly configured your client for persistent sessions (cleanSession=false). If you continue to face issues, it might be helpful to use AWS IoT logging to debug your MQTT sessions and understand what is happening to your connections and sessions over time.

profile picture
EXPERT
Sedat Salman
answered a year ago
  • borg
    a year ago

    Thanks, yes I am using persistent sessions, and the reason I switched to using that versus managing resubscribing myself is because my application has pages that subscribe to 20+ topics and aws has a limit of maximum 8 topics in a subscribe request. It just became a pain when using persistent session is simple. All of this would be solved if AWS exposed "sessionIdentifier" outside of reserved topics or somehow passed it to clients upon connection. That value is all I need on the client.

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