CONNECT race condition in AWS IoT

Question

I have a device with 2 modules which can connect to AWS IoT. They will never be connected at the same time, so I'm planning to use the same `clientId` for both modules. One of the modules is a leader and decides who should be connected: Leader (L) or Follower (F). The network connections they use might be of low quality. I'm wondering if it's possible to have a scenario like this:
1. (F) is connected but because of network issues it has to reconnect and sends CONNECT to IoT
2. (L) wants to take over the connection so tells (F) it takes over the connection. [(L) has high priority message to deliver and can't wait for ACK from (F) that it has disconnected]
3. (L) connects to IoT and sends CONNECT and receives CONACK
4. Network is slow and only now CONNECT sent by (F) arrives to IoT which knocks off (F) from IoT

Is this scenario possible or IoT takes care of this (for instance using timestamp sent in requests)? I know that (L) can reconnect upon disconnection, but network might be slow/unreliable so it might introduce significant latency which I have to avoid.

Accepted Answer

MQTT does not have a time synchronization protocol, hence AWS IOT Core can only consider the order in which the packets arrive to the gateway. In the case you describe, this will happen:

1. F sends CONNECT 
2. L sends CONNECT
3. L CONNECT is received by AWS IoT Core, hence L is now connected
4. F CONNECT is received (same clientId as L). AWS IoT Core disconnects L and F is now connected
5. L receives a DISCONNECT message. 
6. L reconnects
7. F is disconnected 
6. F should know (according to your internal protocol) that L has taken over the connection, and should not reconnect

CONNECT race condition in AWS IoT

相關內容