How should I reset peer manager ranking

[T IJ]

Hello DevZone,

I am planning on making a system that uses peer manager ranking to determine which oldest bond I need to delete to make room for a new one.

I am using the function 

ret_code_t pm_peer_rank_highest(pm_peer_id_t peer_id);

to set the rank upon successful connection and use 

ret_code_t pm_peer_ranks_get(pm_peer_id_t * p_highest_ranked_peer,
                             uint32_t     * p_highest_rank,
                             pm_peer_id_t * p_lowest_ranked_peer,
                             uint32_t     * p_lowest_rank);

to find out which rank is the lowest.

I've read that pm_peer_rank_highest may return NRF_ERROR_RESOURCES when the rank is equal to UINT32_MAX and that I should manually update the ranks back from 0.

I have not found a way to do this correctly since the variable m_current_highest_peer_rank is static inside the peer manager and I did not found any way to set this back to 0.

Am I missing the function to reset this variable?

I am using SDK 17.0.2 with softdevice 7.2

[Einar Thorsrud]

Hi,

The SDK does not have any support for resetting the peer rank as this is not considered a relevant problem. For this to be a problem the you would have to establish connection to bonded peers 2^32-1 = 4294967295 times (UINT32_MAX as you write) and it is difficult to see how this could ever happen in practice. For instance, if you connect to a bonded peer every second it will take 136 years for this to manifest itself as an issue. So in practice any code you add to do this will just add to the complexity without ever being useful.

[T IJ]

If it theoretically never happens why is it mentioned in the error code? This would suggest me that there is a possibility that it will occur during operation and that I have to make a way to reset the rank levels from the start.

 * @retval NRF_ERROR_RESOURCES      If the highest rank is UINT32_MAX, so the new rank would wrap
 *                                  around to 0. To fix this, manually update all ranks to smaller
 *                                  values, while still keeping their order.

[Einar Thorsrud]

Good questions. I guess it made sense to document corner cases and assumptions when writing API documentation. If you really want to do this, then you can implement something suggested, by updating the FDS records. But the only consequence will be adding dead code that worst case contributes to unnecessary bugs and best case has no use at all.

[T IJ]

Thank you, I think I will try to implement something that will correct this.

I've been told that if you do something and think this situation will never happen that it will happen. Even though it is very unlikely.