AF_DataRequest的问题

AF_DataRequest发送数据，能否保证数据传送到了目的地？是否会丢包/无码？或是在何种情况下会丢包/误码。多谢！

不能，不过会有重传.  重传也失败，可通过confirm事件通知你失败。

参看developer guide 第8章

8. End-to-end acknowledgements
For non-broadcast messages, there are basically 2 types of message retry: end-to-end acknowledgement (APS
ACK) and single-hop acknowledgement (MAC ACK). MAC ACKs are always on by default and are usually
sufficient to guarantee a high degree of reliability in the network. To provide additional reliability, as well as to
enable the sending device get confirmation that a packet has been delivered to its destination, APS
acknowledgements may be used.
APS acknowledgement is done at the APS layer and is an acknowledgement system from the destination device to
the source device. The sending device will hold the message until the destination device sends an APS ACK
message indicating that it received the message. This feature can be enabled/disabled for each message sent with the
options field of the call to AF_DataRequest(). The options field is a bit map of options, so OR in
AF_ACK_REQUEST to enable APS ACK for the message that you are sending. The number of times that the
message is retried (if APS ACK message isn’t received) and the timeout between retries are configuration items in
f8wConfig.cfg. APSC_MAX_FRAME_RETRIES is the number of retries the APS layer will send the
message if it doesn’t receive an APS ACK before giving up. APSC_ACK_WAIT_DURATION_POLLED is the time
between retries.

多谢！

如果在app里面，发送数据之后，接受端发一个回包，发送端直到接收到这个回包，再发送下一个数据，这样应该就是最可靠的办法了吧？有2个问题

1，这种是否和APS ACK的方式原理相同？

2，通过发APS ACK大概会占用多少带宽？在mesh组网的时候，是否会对性能有很大影响？

1. 是的。

2. 你是说延迟吧？带宽如何衡量？这和你的跳数，可能的重传应该都有关系。这个肯定对网络容量有影响。你节点越多，肯定影响越大。

老实说，zigbee 组大网时，更适合周期性上报的应用，数据反正累加，也不用担心偶尔一次数据没有完成传输。

多谢你的答复，很清楚明了。实际2530组网的传输带宽能到多少？能支持多少节点组网比较常用？考虑协调器用2538，是否对整体带宽有明显改善？

实际带宽受限于重传，退避等，没有具体数据。一般3，50个节点吧， 2538是M3核速度肯定要快一些，但通讯是双向的，而且zigbee是网络概念，

不是一个节点占住信道一直发。 你可以重新post一个话题，再讨论。

这段资料我看懂了，但是在代码上不知道怎么去实现？

介意贴个只和这个功能相关的代码片段参考一下吗