Can bluetooth or wifi stream (spp) ever skip bytes or be damaged?

Question

Something has been bothering me for years. I work with a lot of bluetooth and recently wifi streams (spp). These streams always connect to specific devices, and communication is done using simple byte commands.

I program some of the devices (their microcontrollers) myself and there, I should always check if there is a signal on the wire, what I expect, send and check on crcs.

Somehow I want to do the same on my smartphone, because I access my streams using readByte and read bytes by bytes, and I always wonder if it is possible that a) one byte from the message may be missing b) messages arrive mixed or "out of sequence"

I do not know how this works. Does it check every message with crc and request the message again if it was damaged? Or does he blindly pass every byte to my readByte method?

If the device sends a message a and then b, is it possible that the recipient receives b before a and sends my code b to or even mixes bytes such as lightning and gives me [0], then b [0], then [1 ] etc.

How much trust do you have in these flows? Some clarifications will be appreciated.

Answer 1

I think you sleep well. WiFi and Bluetooth are based on a network of packet switches, each package comes with a crc processor, and the physical layer has built-in control over congestion and channel quality control - therefore, in addition to extremely rare firmware errors, it is actually more reliable than a wired serial connection.

In other words, error correction occurs at a lower level than you use.

Answer the question about the order in which packets arrive: this problem does not affect point-to-point protocols. Packets are reordered when they travel along different routes, so there is no problem if there are no other routes.

You will get the same bytes in the same order if you use byte-oriented streams using these protocols, because they are designed for this purpose. On the other hand, there is no packet access, but Android does not provide you with the means to use it.

Answer 2

It seems to me that if you ever found out about the Computer Network OSI Model , you will understand what I'm talking about better.

First , TCP/IP has nothing to do with Bluetooth . TCP is a transport layer protocol, while Bluetooth will be a lower layer protocol. This way you can use TCP or UDP over Bluetooth the same way you use TCP and UDP over Ethernet.

Second one . If data is transmitted via Bluetooth devices, TCP will be used. TCP use congestion recovery algorithms to ensure data transfer accurately. Modern TCP implementations include four interwoven flow control algorithms: slow start , congestion avoidance , fast relay, and fast recovery . So, if you want to know more about this, you can search the Internet. Because they are more likely to be more theoretical than programmatic.

Answer 3

Well, with data corruption, I have no good idea. But “mix bytes like lightning and give me [0], then b [0], then [1]” should not be.

I built an application that parses nmea messages from an external Bluetooth GPS. I will not check anything and do not know how the application works.