Google附近的连接2.0功能 [英] Google Nearby Connections 2.0 capabilities

问题描述

我正在评估Google附近的连接2.0，尤其是在评估其协同效应.为此，我将在完全脱机的情况下针对Wifi，蓝牙和BLE进行评估，而无需任何路由器.

I am evaluating Google Nearby connections2.0 more specifically evaluating the synergy effect of it. For this I am evaluating it against Wifi, Bluetooth and BLE in totally offline scenario, without any router.

场景

一台设备在做广告，其他所有设备(总共8台设备)在做广告.成功连接后，我将向每个连接的设备直接发送20B，200B和33KB大小的简单文件，持续30秒.

One device is advertising, all others (8 devices in total) are discovering. On successful connection, I am sending simple Files of 20B, 200B and 33KB sizes for 30 secs straight to each connected device.

我正在使用android三星S6 SM-G920F 装有android版本:6.0.1和playservices版本12.8.74的设备

I am using android Samsung S6 SM-G920F devices with android version: 6.0.1 and playservices version 12.8.74

我有以下问题/疑问

Q1 :首先，最多可以模拟连接3到4个设备，这比其他设备断开连接的结果更多.即使仅连接了3台设备，并且我连续发送消息30秒钟，其中一台设备还是断开了连接?用简单的话来说，与任何设备的连接不能维持超过45秒.通常会在25到45秒之间断开连接

Q1: First of all at max 3 to 4 devices could be connected simulatenously more than this results into disconnect event of other devices. Even if only 3 devices are connected, and I am continuously sending message for 30seconds, one of them disconnected ? In simpler words, cannot sustain connectivity with any device for more than 45 secs. usually disconnection occur between 25 - 45 secs

第二季度:我无法像这样使用Wifi一样连续30秒连续发送消息/文件

Q2: I cannot send message/file continuously for 30 seconds like we can do with the Wifi like this

While(30sec){
   bluetoothSocket.outputStream.write(bytes)
}

因为我尝试执行此操作，所以我的工作量过多.我必须等待 onTransferPayLoadUpdate()

Because if I try to do this then I got the exception of too much work.I have to wait for the the callback in onTransferPayLoadUpdate()

第3季度:如果我尝试将1MB或更多的文件发送给其他对等方，则对等方在 onPayloadReceived 回调中成功接收到该文件，但服务器/发送方收到成功状态经过太多的延迟.就我而言，它是在客户端回调后1分钟到5分钟之间.在服务器上收到成功回调之前，我无法发送新文件.如果我尝试在获取回调之前发送它，则不会发生任何事情.从字面上看没什么.因此，从本质上讲，我只能发送一次1MB的文件，然后必须重新发送这两个设备来发送另一个文件.

Q3: If I try to send the file of 1MB or more to other peers, peer received the file successfully in onPayloadReceived callback but server/sender receive the successful status after too much delay. In my case it's between 1 mins to 5 mins after client callback. And I cannot send new file until I got the success callback on server. If I try to send it before getting the callback, nothing happens. Literally nothing. So In essence I can only send file of 1MB once then I have to resent both the devices to send another file.

推荐答案

这应该分为3个独立的问题.它可以帮助将来的开发人员更轻松地搜索.因此，如果您有时间这样做，请告诉我，我也将拆分答案.但是无论如何，让我们开始吧！

This should be broken up into 3 separate questions. It helps future developers search easier. So if you get the time to do that, let me know and I'll split up my answer as well. But anyway, let's get into it!

A1:附近的连接"有3种不同的策略.策略越受限制，我们可以使用的媒体类型就越多.因此，考虑到这一点，并且不涉及路由器，P2P_CLUSTER将仅使用蓝牙.这是最通用的策略，因此可用媒介最少.

A1: Nearby Connections has 3 separate strategies. The more limited the strategy, the more types of mediums we can use. So with that in mind, and with no router involved, P2P_CLUSTER will only use Bluetooth. It's the most general strategy, so it has the fewest mediums available.

所有Android设备均使用移动蓝牙芯片，不幸的是它们较弱(但体积小且对电源敏感)，这导致它们的理论上设备限制为7个，而实际设备限制为3个至4个.更糟糕的是，智能手表和配对耳机也吞没了这个极限.这就是为什么您遇到问题的原因.

All Android devices use mobile Bluetooth chips, which are unfortunately weak (but small and power sensitive), and that causes them to have a theoretical 7 device limit but a practical 3~4 device limit. To make things worst, that limit is eaten up by smart watches and paired headphones as well. That's why you're running into problems.

P2P_STAR和P2P_POINT_TO_POINT都受到更大的限制，因为您无法在任何方向上进行连接.您需要事先选择主机的主人，并让所有人扫描并连接到该主机.但是，您可以获得WiFi热点的额外好处，该热点具有更高的带宽和受支持的同时运行设备的数量.我已经看到7个设备愉快地连接到了Lollipop设备.

P2P_STAR and P2P_POINT_TO_POINT are both much more limited, because you can't connect in any direction. You need to choose who the host is beforehand and have everyone scan for and connect to that host. But you get the added benefit of WiFi hotspots, which have higher bandwidth and a larger number of simultaneous devices supported. I've seen 7 devices happily connected to a Lollipop device.

如果您想超越10s和100s，并且路由器不可用，则必须构建一个网状网络.如果您有兴趣，我可以将您链接到如何执行此操作的示例.在Connections中我们不提供对此的支持，但是其他人已经在我们之上建立了网格，因此我们可以为您指明正确的方向.

If you want to go beyond that, into the 10s and 100s, and a router isn't available, you'll have to build a mesh network. I can link you to examples of how to do that if you're interested. We don't offer support for that within Connections, but others have built meshes on top of us so we can point you in the right direction.

A2:是否可以包含所看到的错误的堆栈跟踪信息?Payload.Type.STREAM用于连续发送数据.其他有效负载类型也应该也起作用，排除一些罕见但潜在的问题，例如BYTE有效负载会填满手机RAM.

A2: Can you include a stack trace of the error you're seeing? Payload.Type.STREAM was built for continuously sending data. The other payload types should also work too, baring some rare but potential issues like BYTE payloads filling up the phones RAM.

A3:两个设备都需要等待onPayloadTransferUpdate(SUCCESS).onPayloadReceived只是一个标头，表示有传入的文件或流，但尚未接收到数据.对于字节有效负载，我们实际上是在标头内发送完整的字节有效负载，因此这是唯一可立即获得数据的时间.

A3: Both devices need to wait for onPayloadTransferUpdate(SUCCESS). onPayloadReceived is only a header, and means that there's an incoming file or stream but that the data hasn't been received yet. For byte payloads, we actually send the full byte payload inside the header so that's the only time data is immediately available.

这篇关于Google附近的连接2.0功能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！