ESP-Mesh-Lite的作用好像不太完备？ (AEGHB-1193)

[raspi404]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Provided a clear description of your suggestion.
• Included any relevant context or examples.

Issue or Suggestion Description

• no router 模式经过现场部署及多次测试，观察出以下现象：

1. mesh lite 提供的 espnow 只在同一个 mesh 内两个设备直接信号覆盖范围内，这两个设备能借助 espnow 互相通信（和这两个设备所在的mesh层级无关）。

2. mesh lite 环境中，使用 socket 通信，子节点可以经过多级转发（可能距离超出两个设备的直接信号覆盖范围），和根节点建立通信，但根节点或者子节点无法跨越两个设备的直接信号覆盖范围和另一个子节点建立连接。

• 得出结论：

1. 想要通过节点转发实现长距离通信，只能由开发者通过路由表查表一步一步转发来实现。但是配置CONFIG_MESH_LITE_NODE_INFO_REPORT 后，通过 esp_mesh_lite_get_nodes_list 获得的节点列表，并不能表达mesh网络的所有节点的上下级关系（例如不能知道某个level3节点的父节点是哪个level2节点）
2. 如果 esp_mesh_lite_get_nodes_list 这个方式不能使用，想要构造出路由表，每个子节点在IP_EVENT_STA_GOT_IP相关事件触发后，定期通过 socket 向根节点上报当前节点的路由状态，由根节点拼装分发，这个方式是否合理？

• 另外是不是我的使用方式有问题，怎么会有这么多问题。而且如果不把消息转发的功能实现，使用mesh lite后节点之间的通信距离在某些情况下相当于 sta->ap->sta （根节点开启wifi ap，所有子节点连接这个wifi）的一半？

[xcguang]

拓扑结构在我们新的版本已经实现，获取方式参考： #186

[raspi404]

拓扑结构在我们新的版本已经实现，获取方式参考： #186

我是个人开发者，可能无法搞定为企业级用户打造的专属解决方案仓库。

如果这些问题不算 mesh lite 应该被修复的缺陷，那我上文所列的个人解决方法是合理的吗？有没有捷径（我不想弄太多重复冗余的实现）

[xcguang]

esp_mesh_lite_get_nodes_list 其实是我们给用户参考的，你可以再补充父节点的解析，就可以知道父节点信息形成拓扑结构了。meshlite 为树状结构，主要是为了基于socket 编程和外部网络通讯的；如果要实现网络内部的通讯，需要通过根节点进行数据中转，比如子节点A将数据报给根节点 ，根节点再广播给子节点

[raspi404]

esp_mesh_lite_get_nodes_list 其实是我们给用户参考的，你可以再补充父节点的解析，就可以知道父节点信息形成拓扑结构了。meshlite 为树状结构，主要是为了基于socket 编程和外部网络通讯的；如果要实现网络内部的通讯，需要通过根节点进行数据中转，比如子节点A将数据报给根节点 ，根节点再广播给子节点

我不想太依赖广播加重一些节点的负担，过于依赖根节点做消息中转可能没那么健壮。
我在测试中，使用 socket 在 meshlite 的每个星形结构的节点间通信是安全的（我不太确定我的结论是否准确，想问问你），我想更多的借助最短路径的消息转发。

使用 socket 通信时，esp_mesh_lite_get_nodes_list返回 ip 值是有歧义的（例如对于子节点，其父节点的ip尾数是 x.x.x.1 ），我可能会参考 esp_mesh_lite_get_nodes_list 的做法做一个对于我的需求更简洁的，但是补充修改有点力不从心