# Subject-ID Assignment **URL:** \ **Category:** Applications & Usage\ **Created:** [May 9, 2023, 1:54pm UTC](https://forum.opencyphal.org/t/subject-id-assignment/1882 "2023-05-09T13:54:15Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [May 9, 2023, 2:10pm UTC](https://forum.opencyphal.org/t/subject-id-assignment/1882/2 "2023-05-09T14:10:11Z")
The idiomatic approach is to assign a separate Subject-ID per sensor, as you described. The libcanard RAM utilization per session is something that may require revision. For example, in libudpard, where the maximum number of nodes is 65535 (from 0 to 65534), the static table approach adopted in libcanard is no longer viable, so we use a O(\log n) tree instead; perhaps the same approach should be applied in libcanard as well, possibly as a build option. The compromises you listed are well-known indeed, and they are known to cause significant issues in practical deployments. I advise avoiding them. For the bloat issue you mentioned, check out this RFC: [RFC: add array of ports](https://forum.opencyphal.org/t/rfc-add-array-of-ports/1878). Any input would be appreciated (I am yet to provide mine). --- _[View the full topic](https://forum.opencyphal.org/t/subject-id-assignment/1882)._