Google Nearby 中的传入文件有效负载感知和 onPayloadTransferUpdate 频率

Posted 2023-02-23

【中文标题】Google Nearby 中的传入文件有效负载感知和 onPayloadTransferUpdate 频率

【英文标题】：Incoming File Payload awareness in Google Nearby and onPayloadTransferUpdate frequency

【发布时间】：2018-07-10 09:30:57

【问题描述】：

在一个非常简单的场景中，我通过 Nearby 在两部手机之间发送文件。

发送者简单地制作一个Payload.Type.FILE类型的Payload并将其发送给接收者。

在接收方方面，我想知道文件传输何时开始（接收方何时知道传入的文件）。在文档中它说明了onPayloadReceived:

根据有效负载的类型，在调用时可能已收到或未收到所有数据。使用 onPayloadTransferUpdate(String, PayloadTransferUpdate) 获取收到的数据状态的更新。

但是，onPayloadTransferUpdate 似乎仅在文件的重要部分已传输后才被调用。根据我的测试，每次附近收到至少 2^16 个字节时都会调用它。

简而言之，我想知道接收方是否可以在我的 FILE 的任何字节实际发送之前知道有效负载传输的开始，即update.getBytesTransferred() == 0。

另外，为什么onPayloadTransferUpdate 每 2^16 字节被调用一次？一直都是这个尺寸吗？

【参考方案1】：

是的，onPayloadReceived() 回调仅在收到第一个块时触发是正确的。

就像@Xlythe 提到的那样，如果您想在发送方开始传输时向接收方发送信号，您可以从发送方发送一个字节有效负载，让接收方知道一个文件即将到来。

在任何情况下，鉴于我们当前的块大小为 64k，传输开始和接收器收到第一个块之间的延迟应该是（再次，正如@Xlythe 提到的）

这不是你看到的吗？

【参考方案2】：

Nearby Connections 会在字节离开设备后立即通知您（通过 onPayloadTransferUpdate），而不是在远程端收到它们后通知您。所以你看到的是预期的。延迟最多为 1 秒。

如果该延迟不可接受，请考虑发送 BYTE 有效负载作为接收方的接收确认。

至于 onPayloadTransferUpdate 中给出的大小，这是当前我们将文件分解成的块大小。不要依赖大小作为常数，因为它不能保证，我们会对其进行调整。

【讨论】：

我指的是远程端的onPayloadTransferUpdate 回调。我相信只有在远程端收到一整块后才会调用它，对吗？远程端无法知道有效载荷传输何时开始？

哦，你是对的。 onPayloadReceived 仅在第一个块之后接收。您可以在发送 FILE 有效负载之前发送 BYTE 有效负载（这也可以让您发送其他元数据，例如文件名）。