[参考译文] CC3200：通过 mDNS 发现不可靠

您好 Carsten、

我已将其分配给我们的一位软件专家以提供支持。 周末请留出几天的时间进行回复。

您好！

您使用的是什么电源策略？

如果您使用 的是 sl_normal_policy、您能否尝试 sl_always_ON_policy 并测试统计数据是否有所改善？

此致、

Shlomi

感谢您的建议。 我们添加了更多用于测试的器件、并对策略进行了建议的修改(器件5-9)。

不幸的是，这似乎没有影响统计数字。 还有其他想法可以尝试吗？

------------------------
基准测试 MDNS
在26秒内扫描25次
------------------------
器件2      48%(sl_normal_policy)
器件3      48%(sl_normal_policy)
器件4      48%(sl_normal_policy)
器件5      52%(sl_always_ON_policy)
器件6      52%(sl_always_ON_policy)
器件7      48%(sl_always_ON_policy)
器件8      48%(sl_always_ON_policy)
器件9      44%(sl_always_ON_policy)
mysimplelink 52%(sl_normal_policy、mdns 示例)
RPI           96%
------------------------

您好！

只是为了确保我们不会因为 Wi-Fi 进入睡眠状态而丢失任何数据包。

您能否详细说明您正在应用的 mDNS 发现过程？ 例如、设备是否仅传输 mDNS 多播帧、移动应用程序是否应选择它？ 或者、器件是否还需要接收某些内容(例如、"关闭环路")？

此外、您是否有一个可以提供更多照明的监听器？

您使用的是什么服务包版本？

Shlomi

我们的器件都连接到相同的接入点、使用应用程序的终端器件也是如此。 该应用程序会发送正常的多播查询、并等待具有 CC3200的器件的响应、然后连续连接到这些器件。 由于各个器件部分缺乏响应、因此并非所有器件都以这种方式实现。

提出几项要求并收集答案原则上会更好，但从我们的角度来看，这只是一个权宜之计，最好首先得到可靠的答案。

来自 CC3200器件的这些响应的性质是多播？ 我想了解的是查找这些设备的机制如何工作、所有多播、单播、其他？

如果发现设备、是否可以连接正常？

非常感谢对该程序的详细说明。

我问我做实验的同事、详细了解他是如何做的、随附的图片对此有何帮助？

在每种情况下找到的 CC3200都可以连接到应用程序、而不会出现任何问题。

服务包附录：有些服务包较旧、但有些服务包也是最新的(以便能够比较影响)、就像原始 LaunchXL (CC3100_CC3200_ServicePack_1.0.1.15-2.15.0.1)一样。

感谢您的分享。

根据我的理解、请求和响应都是通过 mDNS 传输的。

现在的问题是 CC3200在接收这些消息或发送响应时是否遇到问题。

使用 always_on 电源策略的实验应该改进 RX 侧(显然我们没有看到很多改进)。 在 TX 端、它应该发送的实际"时隙"不存在、只要有数据包要发送、就应该是好的。

对其进行深入研究的唯一方法是使用空气嗅探器(此处的方法看起来像是以太网捕获)。 您是否具有此功能？

此外、我们还可以从 NWP 日志捕获中获得一些好处。 此过程在以前的一些帖子中进行了介绍、例如 https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1063445/cc3200-enterprise-network-connection-issue/3935222#3935222

此致、

Shlomi

此外、如果有可能获得一个过程的代码片段、这是最好的。

只是想了解您是将 mDNS 用作广播器、发现还是两者兼而有之。

是否支持 sl_NetAppDnsGetHostByService()/sl_NetAppGetServiceList()、 sl_NetAppMDNSRegisterService()，两者都是？

Shlomi

我们只使用 sl_NetAppMDNSRegisterService()的发现 ，以下是相应的函数：

long ConfigureMDNS (signed char *service_name, signed char *service_description, int port, char enable)
{
   long iretvalmDNS;
   //Registering for the mDNS service.
    char dev_domain[65]="xyz.";


    memcpy(&dev_domain[strlen("xyz.")],(const char*)service_name,strlen((const char*)service_name));

    iretvalmDNS = sl_NetAppMDNSUnRegisterService((const _i8*)dev_domain,\
                    (unsigned char)strlen((const char*)dev_domain));
    if (enable)
    {
      iretvalmDNS = sl_NetAppMDNSRegisterService((const _i8*)dev_domain,\
                    (unsigned char)strlen(dev_domain),\
                    service_description,\
                    (unsigned char)strlen((const char*)service_description),
                    gl_DeviceInfo.service_port, 2000, 1); // SERVICE_PORT,2000,1);
    }

    return iretvalmDNS;
}

最初、我们只使用服务浏览器应用程序来显示网络中的设备。
当器件响应时、它们通常会非常快(<300ms)、但在其他情况下、即使等待很长时间、也不会显示它们。

我将介绍  NWP 日志捕获功能、我已经注意到、我们在硬件设计中将该引脚用于其他目的。

由于 Launchpad 的行为与我们的器件类似、我已首先在此器件上测试了网络日志记录、并附加了生成的日志文件、这是否是正确的格式？

e2e.ti.com/.../3000.capture.zip

您好！

是的、这是可以的。 但是、对于 mDNS 及其失败的原因、我们看不到太多。

总而言之、在某种程度上、探测设备似乎看不到 mDNS 帧。 您能告诉我们您收集统计数据的时间有多长？

我想理解的是、CC3200器件是否只是按预期停止广播、因此您不再看到它。

简而言之、您能否添加以下 get 命令来获取 mDNS 广播参数并报告输出？

{
    SlNetAppServiceAdvertiseTimingParameters_t mdnsStruct;
	_u8 optionLen = sizeof(mdnsStruct);
	
	sl_NetAppGet(SL_NETAPP_MDNS_ID, SL_NETAPP_MDNS_TIMING_PARAMS_OPT, &optionLen, (_u8 *)&mdnsStruct);
	
	UART_PRINT("MDNS parameters: t %d, p %d, k %d, RetransInterval %d, Maxinterval %d, max_time %d\n\r", mdnsStruct.t, mdnsStruct.p, mdnsStruct.k, mdnsStruct.RetransInterval, mdnsStruct.Maxinterval, mdnsStruct.max_time);
}

Shlomi

我是否需要在其他地方进行其他更改？ 只是运行代码是否足够、或者是否应该定期重复该器件？

我刚刚在旧版本上进行了测试、此后一些定义发生了变化。

您可以在 netapp.h 头文件下查看所有内容。

• 使用  SL_NetApp_MDNS_ID 的 SL_NET_APP_MDNS_ID
• 使用 netapp_set_get_mdns_timing_Params_opt 而不是 sl_netapp_mdns_timing_Params_opt
• 不确定为什么在最后两个问题上失败。 API 为：
  • _i32 sl_NetAppGet (const _u8 AppId、const _u8选项、_u8 * pOptionLen、_u8 * pOptionValue)；

您能否再次检查您是否拥有此 API @NetApp.h？

Shlomi

这很有帮助、下面列出了来自调试器的结构内容：

感谢您的参与！ 我们已经尝试过修改后的参数、 它变得越来越糟糕、而不是更好。 我们注册的服务"_UART._tcp.local"的情况更糟、CC3200的现有服务"_http._tcp.local"在直接比较中似乎更好。 它是否具有单独的参数以及在何处配置？

不可以、这些参数适用于内置和新服务、完全相同。

您是否看到了重大差异？

您是否有无线监听器、我们可以在其中实际看到 mDNS 帧？

我们再次运行统计程序、对于相同的器件、使用"_http._tcp.local"的服务比使用"_uart._tcp.local"的服务更具再现性。 此外、列出服务的简单 Android 应用程序(例如 服务浏览器) 也得出了相同的结论。  这两种服务的不同行为是否有解释？

如果选择>0，参数“RetransInterval”是否会导致广播进程在时间间隔内执行几次(单位秒？)？

您好！

实际上、内部和注册的用户都应该出现在相同的 mDNS 广播中、因此不清楚为什么会看到不同的统计数据。

关于"重新发送间隔"、它表示在发送重复的通知消息之前等待的节拍数(在新情况下为3)。

Shlomi

通过向器件分配唯一的服务名称 xyz1._UART..._tcp.local、我们设法找到了 UART 服务以及原始 http 服务。 但是、这并没有解决最初的问题、因此我们调整了搜索策略。 现在、我们搜索更短的时间、但在等待一段时间后、每行搜索几次、并聚合找到的器件。 这样、几次运行后、所有器件都能可靠地找到。 但是，如果有进一步的建议来改变这一事业，我们将乐意尝试这样做。 总之、感谢大家的支持。