You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Start in a state where the secure session table is full (with one of the slots being the pre-allocated session that CASEServer will use for new incoming CASE attempts), with only one session per peer in the table. Ideally all on the same fabric.
Have a CASE initiator that does not have any existing sessions in the session table try to establish CASE.
The new CASE session is established.
We try to allocate a new secure session to listen for more incoming CASE (see step 1).
This evicts the just-established CASE session.
This happens because CASE passes the just-established ScopedNodeId as an eviction hint to session allocation. When DefaultEvictionPolicy does its sort it:
Prioritizes fabrics with more sessions. If all the sessions are on the same fabric, this is a no-op.
Prioritizes sessions that match the hint's fabric. Again, if there is only one fabric this is all a no-op.
Prioritizes peers that have more sessions to them. Since by assumption there is one session per peer, this is also a no-op.
Prioritizes sessions that match the eviction hint. This will prioritize the just-established session.
Only after that are things like defunct state and activity time checked. So you can have lost of defunct sessions to various peers and end up evicting the just-established session.
In practice we have a nonempty hint in two situations:
For a CASE initiator, it's the peer ID we're establishing a session to. In this case, we can assume that we do not have an existing active session, since CASESessionManager would have just used it.
For a CASE responder, it's the peer ID that we just established a new session. In that case we definitely have an active session and we do not want to evict it.
So what I would propose is that we treat a session as not matching the eviction hint if it's (1) active and (2) has mNumMatchingOnPeer == 0 (which means it's the only active session to that peer).
The text was updated successfully, but these errors were encountered:
When we establish a session as a CASE responder, we try to allocate a new
session to listen to session establishments, and use the
just-established-session's peer ID as the eviction hint.
If we had a bunch of active sessions on a fabric, all to different nodes,
this would cause the just-established session to be evicted, since it matched
the hint.
The fix is to only consider sessions for eviction based on the hint if they are
either non-active or not unique sessions to the peer (at which point, the
just-established session should be last in priority order for eviction).
Fixesproject-chip#30728
When we establish a session as a CASE responder, we try to allocate a new
session to listen to session establishments, and use the
just-established-session's peer ID as the eviction hint.
If we had a bunch of active sessions on a fabric, all to different nodes,
this would cause the just-established session to be evicted, since it matched
the hint.
The fix is to only consider sessions for eviction based on the hint if they are
either non-active or not unique sessions to the peer (at which point, the
just-established session should be last in priority order for eviction).
Fixesproject-chip#30728
When we establish a session as a CASE responder, we try to allocate a new
session to listen to session establishments, and use the
just-established-session's peer ID as the eviction hint.
If we had a bunch of active sessions on a fabric, all to different nodes,
this would cause the just-established session to be evicted, since it matched
the hint.
The fix is to only consider sessions for eviction based on the hint if they are
either non-active or not unique sessions to the peer (at which point, the
just-established session should be last in priority order for eviction).
Fixes#30728
Reproduction steps
This happens because CASE passes the just-established ScopedNodeId as an eviction hint to session allocation. When DefaultEvictionPolicy does its sort it:
Only after that are things like defunct state and activity time checked. So you can have lost of defunct sessions to various peers and end up evicting the just-established session.
Bug prevalence
Every time, given the preconditions
GitHub hash of the SDK that was being used
b379158
Platform
core
Platform Version(s)
No response
Anything else?
In practice we have a nonempty hint in two situations:
So what I would propose is that we treat a session as not matching the eviction hint if it's (1) active and (2) has mNumMatchingOnPeer == 0 (which means it's the only active session to that peer).
The text was updated successfully, but these errors were encountered: