关于广播包的问题

參考一下 www.google.com/url

BCAST_DELIVERY_TIME

The length of time a broadcast message is kept in the broadcast table. Set to 500ms more than retry time. Retry time is defined as PASSIVE_ACK_TIMEOUT * (MaxBroadCastRetries + 1). If a broadcast message is being sent to end devices, then this should be set in accordance withthe polling rate of the end devices. For example 200 might be a good number if the poll rate was set to 10 seconds for the end device.

MAX_BCAST
This is the number of broadcast entries (for data packets) that can be held for the period of BCAST_DELIVERY_TIME. Together, these two settings enforce the settling time for broadcast data packets traversing through the network. For example, if MAX_BCAST_ENTRIES is set to 9, and BCAST_DELIVERY_TIME is set to 10 (seconds), a device could send out 9 sequential broadcast data packets, but would not be able to send out a 10th one until after 10 seconds.

广播是发送给所有节点的

有没有可能会出现丢包的情况，就是协调器广播一条数据给所有节点，节点数量大概20-30，广播包的设置按照默认值，但是有的节点没有收到广播包。

广播和单播对比，哪种方式更占带宽？

节点是終端節點的話不建議用广播，会出现丢包的情况

建议用单播，广播容易造成网络拥堵，也存在丢包的可能

如果是这样的情况：
我想要做一个路由节点和协调器之间的心跳包，路由节点20-30个，初定的方案有以下三种：
1.协调器发送广播，路由节点收到后返回一条数据当做心跳包
2.协调器发送单播数据包给每个路由节点，路由节点收到后返回
3.路由节点发送单播数据包给协调器 ，协调器收到后，再返回
请教一下，哪种方式更合理？

建議你用3.路由节点发送单播数据包给协调器

这样的话，通信数据量不会很大吗？如果节点较多，每隔一段时间，就有很多心跳包发过来，不会很占用带宽吗？

還好吧，我自己試過600多個节点，每隔一段时间发心跳包发也沒有看到有什麼問題

请教一下，你的心跳包是多久一次的，心跳包数据长度是多少