背景
我们在基于 BifroMQ 搭建 IoT 接入层，运维同事希望在控制台上有一个"在线设备列表"页面：能按 tenantId 分页查看当前在线的 MQTT session（userId / clientId / 接入 IP / 连接时间 / cleanStart 等），支持搜索过滤。这是 IoT 运营场景里一个比较高频的需求。
我看到的现状
通读了 bifromq-apiserver 和 bifromq-session-dict 之后，我的理解是：
- HTTP 层：
bifromq-apiserver 暴露的 session 相关接口都是点操作 —— GET /session、GET /session/inbox、DELETE /session、POST /kill，都必须显式传入 tenant_id + user_id + client_id，没有 list/page 类接口。
- RPC 层：
SessionDictService.proto 里只有 get（单条点查）和 exist（存在性批量校验），同样没有 list。
- 数据存储：
SessionRegistry.tenantSessions 是进程内的 ConcurrentSkipListMap，按 (userId, clientId) 排序、不落盘；每个 session-dict-server 节点只持有自己分片的部分。
- 事件侧：通过
IEventCollector 可以拿到 CLIENT_CONNECTED / 各种 DISCONNECTED 事件，业务方可以自己物化一份外部存储。
我的猜测（想跟社区确认）
按现有代码推断，"列出在线 session" 这件事不是疏忽，而是有意没做：
- 分片架构：session 按
tenantId+userId+clientId 一致性哈希分散在多个 session-dict-server，列表需要扇出 + 跨节点合并/分页。
- 规模假设：单租户百万连接的体量下，同步返回列表本身就不现实。
- 职责边界：
apiserver 定位偏控制面（点操作 + 集群拓扑），不承担"业务查询门户"职责；列表类需求由用户通过 event-collector 自己物化到外部存储更合适。
想请教的问题
- 我对设计意图的理解对吗？社区是否明确不打算在 broker 内提供"按租户分页列出在线 session"这类查询，让用户通过 event-collector 自建？
- 如果不是原则上反对，只是优先级 / 实现复杂度问题，是否可以接受这样一个轻量级、为运维 / 对账场景设计的接口？比如：
- 在
SessionDictService 增加 rpc listSessions(...) returns (stream ...)，server 端复用 ISessionRegistry.findRegistrations(tenantId)，基于 ConcurrentSkipListMap 的有序性做游标续传（startKey = userId\u0000clientId，limit 限流）；
apiserver 增加 GET /sessions，通过 service discovery 扇出到所有 session-dict-server 实例，按 key 归并；
背景
我们在基于 BifroMQ 搭建 IoT 接入层，运维同事希望在控制台上有一个"在线设备列表"页面：能按
tenantId分页查看当前在线的 MQTT session（userId / clientId / 接入 IP / 连接时间 / cleanStart等），支持搜索过滤。这是 IoT 运营场景里一个比较高频的需求。我看到的现状
通读了
bifromq-apiserver和bifromq-session-dict之后，我的理解是：bifromq-apiserver暴露的 session 相关接口都是点操作 ——GET /session、GET /session/inbox、DELETE /session、POST /kill，都必须显式传入tenant_id + user_id + client_id，没有 list/page 类接口。SessionDictService.proto里只有get（单条点查）和exist（存在性批量校验），同样没有list。SessionRegistry.tenantSessions是进程内的ConcurrentSkipListMap，按(userId, clientId)排序、不落盘；每个 session-dict-server 节点只持有自己分片的部分。IEventCollector可以拿到CLIENT_CONNECTED / 各种 DISCONNECTED事件，业务方可以自己物化一份外部存储。我的猜测（想跟社区确认）
按现有代码推断，"列出在线 session" 这件事不是疏忽，而是有意没做：
tenantId+userId+clientId一致性哈希分散在多个 session-dict-server，列表需要扇出 + 跨节点合并/分页。apiserver定位偏控制面（点操作 + 集群拓扑），不承担"业务查询门户"职责；列表类需求由用户通过 event-collector 自己物化到外部存储更合适。想请教的问题
SessionDictService增加rpc listSessions(...) returns (stream ...)，server 端复用ISessionRegistry.findRegistrations(tenantId)，基于ConcurrentSkipListMap的有序性做游标续传（startKey = userId\u0000clientId，limit限流）；apiserver增加GET /sessions，通过 service discovery 扇出到所有 session-dict-server 实例，按 key 归并；