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