有些事情困扰了我多年。 我使用很多蓝牙和最近的 wifi 流 (spp)。这些流始终连接到特定设备，并且通过简单的字节命令进行通信。
我自己编程的一些设备（它们的微控制器）在那里我必须始终检查线路上的信号是否符合我的预期，发送并检查 crcs。
不知何故，我想在我的智能手机上做同样的事情，因为我使用“readByte”访问我的流并逐字节读取，我一直想知道是否真的有可能 a) 消息中的一个字节可能会丢失 b) 消息混合或“乱序”到达
我不知道底层硬件做了多少。它是否使用 crc 检查每条消息并在消息已损坏时再次请求该消息？还是盲目地将每个字节传递给我的“readByte”方法？
如果设备发送消息 a 然后 b，接收方是否有可能在 a 之前接收 b 并在 a 之前传递我的代码 b 或者甚至像拉链一样混合字节并给我 a[0] 然后 b[0 ] 然后是 a[1] 等等。
我应该对这些流有多少信任？一些澄清将不胜感激
【问题讨论】：
标签： android bluetooth wifi spp
我没有任何好主意。 但是“像拉链一样混合字节并给我 a[0] 然后 b[0] 然后 a[1] ”不应该发生。
我构建了从外部蓝牙 gps 解析 nmea 消息的应用程序。我没有检查任何东西，也没有检查我的应用如何稳定运行。
【讨论】：
我想你可以睡个好觉了。 WiFi和蓝牙基于包交换网络，每个包都自带crc，物理层内置拥塞和链路质量控制——所以除了极少的固件bug外，它实际上比有线串行连接更可靠。
换句话说 - 纠错发生在比您使用的更低级别..
回答有关数据包到达顺序的问题：点对点协议不受此问题的影响。当它们通过不同的路线旅行时会发生数据包重新排序，因此当没有其他路线时没有问题。
如果您在这些协议上使用面向字节的流，您将以相同的顺序获得相同的字节，因为它们的设计考虑了这一目标。另一方面，数据包访问不是，但 Android 没有为您提供使用它的方法。
【讨论】：
我觉得如果你了解过Computer Network OSI Model，你会更好地理解我在说什么。
首先，TCP/IP 与 Bluetooth 没有任何共同之处。 TCP 是传输层协议，而 Bluetooth 是较低层协议。因此，您可以在蓝牙上使用 TCP 或 UDP，就像在以太网上使用 TCP 和 UDP。
第二，通过蓝牙设备传输数据时，会使用TCP协议。 TCP 使用 congestion recovery algorithms 来确保数据传输准确。 TCP 的现代实现包括四种相互交织的流量控制算法：慢启动、拥塞避免、快速重传和快速恢复。因此，如果您想了解更多有关此的信息，可以搜索互联网。因为它们更倾向于理论而不是程序化。
【讨论】：