-
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
FabricSync example changed to use ScopedNodeId in some locations #35805
Changes from 1 commit
e8a7224
899ebb1
ed52460
737dedd
cbb6c6e
856218e
66c36ff
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -32,27 +32,27 @@ struct ScopedNodeIdHasher | |
{ | ||
std::size_t h1 = std::hash<uint64_t>{}(scopedNodeId.GetFabricIndex()); | ||
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. The NodeId within ScopedNodeId is 64-bit, so is it possible for different ScopedNodeId instances to map to the same hash value, even if the chances are minimized? 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. Collisions are fine. Overall a hash table is best case O(1), when there isn't a collision and worst case of O(n) when there are collisions all the time https://en.wikipedia.org/wiki/Hash_table#Collision_resolution unordered_map's default hashing funtion already maps to size_t right so already there is always a risk of a collision with anything you have ever used in the past |
||
std::size_t h2 = std::hash<uint64_t>{}(scopedNodeId.GetNodeId()); | ||
// Bitshifting h2 reduces collisions where fabricIndex == nodeId resulting | ||
// in hash return of 0. | ||
// Bitshifting h2 reduces collisions when fabricIndex == nodeId. | ||
return h1 ^ (h2 << 1); | ||
} | ||
}; | ||
|
||
// Bi-directional translation between handle for aggregator and information about the | ||
// the device required for fabric admin to communicate with local device. | ||
// the device required for fabric admin to communicate with device. | ||
class BridgeAdminDeviceMapper | ||
{ | ||
public: | ||
std::optional<uint64_t> AddScopedNodeId(const chip::ScopedNodeId & scopedNodeId); | ||
void RemoveScopedNodeIdByHandleId(uint64_t handleId); | ||
std::optional<uint64_t> AddAdminScopedNodeId(const chip::ScopedNodeId & scopedNodeId); | ||
void RemoveScopedNodeIdByBridgeHandle(uint64_t handle); | ||
|
||
std::optional<uint64_t> GetHandleId(const chip::ScopedNodeId & scopedNodeId); | ||
std::optional<chip::ScopedNodeId> GetScopedNodeId(uint64_t handleId); | ||
std::optional<uint64_t> GetHandleForBridge(const chip::ScopedNodeId & scopedNodeId); | ||
std::optional<chip::ScopedNodeId> GetScopedNodeIdForAdmin(uint64_t handle); | ||
|
||
private: | ||
uint64_t mNextHandleId = 0; | ||
// If we ever need more data other than ScopedNodeId we can change | ||
// mHandleIdToScopedNodeId value from ScopedNodeId to AggregatorDeviceInfo. | ||
std::unordered_map<uint64_t, chip::ScopedNodeId> mHandleIdToScopedNodeId; | ||
std::unordered_map<chip::ScopedNodeId, uint64_t, ScopedNodeIdHasher> mScopedNodeIdToHandleId; | ||
uint64_t mNextHandle = 0; | ||
// If admin side ever needs more data other than ScopedNodeId we can change | ||
// mHandleToScopedNodeId value type from ScopedNodeId to AdminDeviceInfo (or something | ||
// of that nature). | ||
std::unordered_map<uint64_t, chip::ScopedNodeId> mHandleToScopedNodeId; | ||
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. The handle in this context seems act as an additional layer of abstraction or indirection, the NodeId is unique, and its corresponding ScopedNodeId is also unique. So why do we need an additional translation layer that requires dynamic allocation and maintenance? 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 is exactly what it is, aggregator code shouldn't care and need to marshal data that is relevant to admin. While today it one thing, in the future it can be more data. I can move to marshaling the ScopedNodeId data instead, but as I mentioned in the PR description on why I didn't not go with that alternative approach. I am okay with changing to the alternative approach if we discuss it based on those merits.
NodeId is not. It is unique on a per fabric basis, but it is not unique.
We either need to pass the ScopedNodeId back and forth, or we need this translation layer. I am more in favor of forward thinking solutions as I don't think marshaling data to systems where that data is meaningless is not scalable only for it to pass that data back, in all other systems that I have worked with this is where you introduce a handle of some sort which is what I was trying to do here. |
||
std::unordered_map<chip::ScopedNodeId, uint64_t, ScopedNodeIdHasher> mScopedNodeIdToHandle; | ||
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. is ScopedNodeIdHasher same as handle? 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. https://en.cppreference.com/w/cpp/container/unordered_map It is the Hash class. Because |
||
}; |
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.
Why not just use ScopedNodeId instead of node_id?
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.
This was discussed in the PR's description. I am open to discussing them but please let me know which point you disagree with