[参考译文] CC3220MODA：当互联网连接不稳定时，ClockSync_GET被长时间卡住

我认为问题出在 SL_NetAppDnsGetHostByName (尝试获取SNTP主机地址时在ClockSync_Get内部调用)，在这种情况下可以阻止。

您可以实施监视程序并调用SL_Stop ，以防它过期，从而停止NWP和 SL_NetAppDnsGetHostByName 执行。

它是否不会在一段时间后超时，或者是否可以在ClockSync代码中进行修复？

Zac

如果我记得正确， 则此API没有超时(它只能在互联网访问丢失时被阻止)。

理论上，此SNTP访问可由应用程序完成(使用外部 DNS实施，或者如果您知道SNTP服务器的IP地址，则不使用DNS)。

同样，实施另一种SNTP解决方案可能是 不必要的返工。 我们不能通过实施某种超时机制在方法本身解决此问题吗？  

您好，

为什么不这样使用呢？

SlNetAppDnsClientTime_t dnsTime;
dnsTime.MaxResponseTime = 1500;
dnsTime.NumOfRetries = 5;
retVal = sl_NetAppSet(SL_NETAPP_DNS_CLIENT_ID,
                      SL_NETAPP_DNS_CLIENT_TIME,
                      sizeof(dnsTime),
                      (unsigned char *)&dnsTime);

一月

我在文档中看到过这种情况，但我想在正常情况下，即拨打DNS电话时关闭互联网。 为此，默认超时也会在几秒钟后生效。 我们遇到的情况是，当互联网非常不稳定时，此呼叫不会返回并永远等待。 复制非常困难，但是我在一些生产设备中看到了这种情况。

您好，Zac，

在我使用~20k的实现中，我还没有看到SL_NetAppDnsGetHostByName()有这样的问题。 我使用CC3220和通用API SL_NetAppDnsGetHostByName()，但我在顶部实现了自己的DNS缓存，它减少了DNS API调用的数量。

但我同意您的申请可能有所不同，您看到的问题是我从未遇到过的。 我认为您唯一的方法是使用自己的DNS实施。 例如，您可以使用LwIP中的DNS解析器。 DNS是相对简单的协议，自己的实现应该是一项容易的任务。

一月

您好Jan，

我的设备 似乎没有足够的资源来实施自己的DNS。 不管怎样，我 想如果API中存在问题(Kobi怀疑 它可能是SL_NetAppDnsGetHostByName，它可能会被卡住) ，那么它必须得到修复。   现在很难获取日志，但 我会尝试。 同时 ，如果有人知道或看到此类问题，请分享进一步的详细信息，以帮助我们进一步调试

Zac

我不确定是否可以在Service Pack中修复此问题。 我们需要先进行检查，然后才能承诺进行此类修复。

同时，主机中有两种解决方案(watchdog + SL_Stop，添加DNS实施)。 添加DNS实现后，可以通过替换  SL_NetAppDnsGetHostByName调用来更新网络库(ClockSync/HTTP/MQTT)。