@@ -938,26 +938,24 @@ CHIP_ERROR ReadClient::ComputeLivenessCheckTimerTimeout(System::Clock::Timeout *
938
938
939
939
//
940
940
// To calculate the duration we're willing to wait for a report to come to us, we take into account the maximum interval of
941
- // the subscription AND the time it takes for the report to make it to us in the worst case.
941
+ // the subscription AND the time it takes for the report to make it to us in the worst case. This latter bit involves
942
+ // computing the Ack timeout from the publisher for the ReportData message being sent to us using our IDLE interval as the
943
+ // basis for that computation.
942
944
//
943
- // We have no way to estimate what the network latency will be, but we do know the other side will time out its ReportData
944
- // after its computed round-trip timeout plus the processing time it gives us (app::kExpectedIMProcessingTime). Once it
945
- // times out, assuming it sent the report at all, there's no point in us thinking we still have a subscription .
945
+ // Make sure to use the retransmission computation that includes backoff. For purposes of that computation, treat us as
946
+ // active now (since we are right now sending/receiving messages), and use the default "how long are we guaranteed to stay
947
+ // active" threshold for now .
946
948
//
947
- // We can't use ComputeRoundTripTimeout() on the session for two reasons: we want the roundtrip timeout from the point of
948
- // view of the peer, not us, and we want to start off with the assumption the peer will likely have, which is that we are
949
- // idle, whereas ComputeRoundTripTimeout() uses the current activity state of the peer.
949
+ // TODO: We need to find a good home for this logic that will correctly compute this based on transport. For now, this will
950
+ // suffice since we don't use TCP as a transport currently and subscriptions over BLE aren't really a thing.
950
951
//
951
- // So recompute the round-trip timeout directly. Assume MRP, since in practice that is likely what is happening.
952
- auto & peerMRPConfig = mReadPrepareParams .mSessionHolder ->GetRemoteMRPConfig ();
953
- // Peer will assume we are idle (hence we pass kZero to GetMessageReceiptTimeout()), but will assume we treat it as active
954
- // for the response, so to match the retransmission timeout computation for the message back to the peeer, we should treat
955
- // it as active.
956
- auto roundTripTimeout = mReadPrepareParams .mSessionHolder ->GetMessageReceiptTimeout (System::Clock::kZero ) +
957
- kExpectedIMProcessingTime +
958
- GetRetransmissionTimeout (peerMRPConfig.mActiveRetransTimeout , peerMRPConfig.mIdleRetransTimeout ,
959
- System::SystemClock ().GetMonotonicTimestamp (), peerMRPConfig.mActiveThresholdTime );
960
- *aTimeout = System::Clock::Seconds16 (mMaxInterval ) + roundTripTimeout;
952
+ const auto & localMRPConfig = GetLocalMRPConfig ();
953
+ const auto & defaultMRPConfig = GetDefaultMRPConfig ();
954
+ const auto & ourMrpConfig = localMRPConfig.ValueOr (defaultMRPConfig);
955
+ auto publisherTransmissionTimeout =
956
+ GetRetransmissionTimeout (ourMrpConfig.mActiveRetransTimeout , ourMrpConfig.mIdleRetransTimeout ,
957
+ System::SystemClock ().GetMonotonicTimestamp (), ourMrpConfig.mActiveThresholdTime );
958
+ *aTimeout = System::Clock::Seconds16 (mMaxInterval ) + publisherTransmissionTimeout;
961
959
return CHIP_NO_ERROR;
962
960
}
963
961
0 commit comments