-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ICD]Trigger resubscription when receiving check-in and subscription has not yet become abnormal #37831
base: master
Are you sure you want to change the base?
[ICD]Trigger resubscription when receiving check-in and subscription has not yet become abnormal #37831
Changes from 9 commits
9f7bed7
2a2df3e
e49f9a6
8dce4be
0860870
9cda649
287a093
2b29328
6a97e2c
1fca04a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -485,6 +485,15 @@ CHIP_ERROR ReadClient::GenerateDataVersionFilterList(DataVersionFilterIBs::Build | |
void ReadClient::OnActiveModeNotification() | ||
{ | ||
VerifyOrDie(mpImEngine->InActiveReadClientList(this)); | ||
|
||
// Note: this API only works when issuing subscription via SendAutoResubscribeRequest. When SendAutoResubscribeRequest is | ||
// called, either mEventPathParamsListSize or mAttributePathParamsListSize is not 0. | ||
VerifyOrReturn(mReadPrepareParams.mEventPathParamsListSize != 0 || mReadPrepareParams.mAttributePathParamsListSize != 0); | ||
|
||
// If mCatsMatchCheckIn is true, it means cats used in icd registration matches with the one in current subscription, | ||
// OnActiveModeNotification continues to revive the subscription as needed, otherwise, do nothing. | ||
VerifyOrReturn(mReadPrepareParams.mCatsMatchCheckIn); | ||
|
||
// When we reach here, the subscription definitely exceeded the liveness timeout. Just continue the unfinished resubscription | ||
// logic in `OnLivenessTimeoutCallback`. | ||
if (IsInactiveICDSubscription()) | ||
|
@@ -493,6 +502,19 @@ void ReadClient::OnActiveModeNotification() | |
return; | ||
} | ||
|
||
// If the server sends out check-in message, and there is a tracked active subscription in client side at the same time, it | ||
// means current client does not realize this tracked subscription has gone, and we should forcibly timeout current | ||
// subscription, and schedule a new one. | ||
if (!mIsResubscriptionScheduled) | ||
{ | ||
// Closing will ultimately trigger ScheduleResubscription with the aReestablishCASE argument set to true, effectively | ||
// rendering the session defunct. | ||
Close(CHIP_ERROR_TIMEOUT); | ||
return; | ||
} | ||
|
||
// If the server sends a check-in message and a subscription is already scheduled, it indicates a client-side subscription | ||
// timeout or failure. Cancel the scheduled subscription and initiate a new one immediately. | ||
TriggerResubscribeIfScheduled("check-in message"); | ||
} | ||
|
||
|
@@ -503,12 +525,6 @@ void ReadClient::OnPeerTypeChange(PeerType aType) | |
mIsPeerLIT = (aType == PeerType::kLITICD); | ||
|
||
ChipLogProgress(DataManagement, "Peer is now %s LIT ICD.", mIsPeerLIT ? "a" : "not a"); | ||
|
||
// If the peer is no longer LIT, try to wake up the subscription and do resubscribe when necessary. | ||
if (!mIsPeerLIT) | ||
{ | ||
OnActiveModeNotification(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So I am trying to understand why it's OK to remove this. The reason this seems to be here is that it's envisioning us having two subscriptions, one of which (call it A) is watching for peer type change and one of which (call it B) is IsInactiveICDSubscription(). When the transition to SIT is observed, B will no longer get any OnActiveModeNotifications, so how will it get out of the "inactive ICD subscription" state? Of course if A does not exist and we just have B, and it's in the "inactive ICD subscription" state and then the server changes to A SIT, I think we just get stuck; that seems to be a hole in the whole logic of this stuff, including the spec? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You are right, the current change does not work on the below scenario
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. updated the code.
|
||
} | ||
} | ||
|
||
CHIP_ERROR ReadClient::OnMessageReceived(Messaging::ExchangeContext * apExchangeContext, const PayloadHeader & aPayloadHeader, | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -351,11 +351,17 @@ class ReadClient : public Messaging::ExchangeDelegate | |
* Re-activate an inactive subscription. | ||
* | ||
* When subscribing to LIT-ICD and liveness timeout reached and OnResubscriptionNeeded returns | ||
* CHIP_ERROR_LIT_SUBSCRIBE_INACTIVE_TIMEOUT, the read client will move to the InactiveICDSubscription state and | ||
* resubscription can be triggered via OnActiveModeNotification(). | ||
* CHIP_ERROR_LIT_SUBSCRIBE_INACTIVE_TIMEOUT, the read client will move to the InactiveICDSubscription state and | ||
* resubscription can be triggered via OnActiveModeNotification(). | ||
* | ||
* If the subscription is not in the `InactiveICDSubscription` state, this function will do nothing. So it is always safe to | ||
* call this function when a check-in message is received. | ||
* call this function when a check-in message is received. | ||
* | ||
* If the server sends out check-in message, and there is a active tracked active subscription in client side at the same time, | ||
* it means current client does not realize this tracked subscription has gone, and we should forcibly timeout current | ||
* subscription, and schedule a new one. | ||
Comment on lines
+360
to
+362
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This comment does not match what the API actually does, really. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. rewrite the comments, thanks |
||
* | ||
* This API only works when issuing subscription via SendAutoResubscribeRequest. | ||
*/ | ||
void OnActiveModeNotification(); | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Matches which side? Should be "our side of the current subscription" or something, right?
But do we really want to push this off onto the API client? Or just examine the fabric table?
And if we do push this off onto the API client, as this PR does, then should this boolean just be
mResetSubscriptionOnCheckin
?