4 ms·

It isn't even the API vendors' fault necessarily. Compared to HTTP/TCP/IP, abstractions between layers of the BLE stack are extremely leaky. Examples: indicati

It isn't even the API vendors' fault necessarily. Compared to HTTP/TCP/IP, abstractions between layers of the BLE stack are extremely leaky. Examples: indicating choice of PHY coding and channels in the equivalent of a `listen/connect` call, or the three different but intertwined places where fragmentation/reassembly can happen. Being effective with BLE requires deep understanding of the entire stack, and since it is difficult for a single person to have such level of understanding, we get bugs. By comparison, being effective with HTTP does not require one to know anything about the PHY layer, or TCP stream reassembly. I suspect this is due to not having enough independent implementations of each layer - Bluetooth is designed and standardized by one committee, and the entire stack usually implemented as a single "thing", making it too easy to break abstraction when a new feature needs to be added.

arcticbull 7y ago
> Being effective with BLE requires deep understanding of the entire stack, and since it is difficult for a single person to have such level of understanding, we get bugs. Bluetooth or LE? LE with GATT in my experience deals with none of this. At least not on an Apple product, CoreBluetooth hides all of this from me as an iOS or macOS developer.
- sratner 7y ago
  Apple does hide most of this, but consider that an iPhone app isn't the BLE product most developers are building, rather it is the device that iPhone app talks to, and where the bugs lurk. (Not that Apple doesn't have its fare share of BLE bugs at the chipset/driver level, which resurface with every new iOS release.)
omeid2 7y ago
> By comparison, being effective with HTTP does not require one to know anything about the PHY layer, or TCP stream reassembly. Maybe not PHY, but you definitionally need to understand TCP, in fact, you have keep-alive and timeout headers that are directly related to TCP. Further more, HTTP/2 is a whole another level of leaky when it comes to HTTP/TCP.

arcticbull 7y ago

> Being effective with BLE requires deep understanding of the entire stack, and since it is difficult for a single person to have such level of understanding, we get bugs. Bluetooth or LE? LE with GATT in my experience deals with none of this. At least not on an Apple product, CoreBluetooth hides all of this from me as an iOS or macOS developer.

sratner 7y ago
Apple does hide most of this, but consider that an iPhone app isn't the BLE product most developers are building, rather it is the device that iPhone app talks to, and where the bugs lurk. (Not that Apple doesn't have its fare share of BLE bugs at the chipset/driver level, which resurface with every new iOS release.)

omeid2 7y ago

> By comparison, being effective with HTTP does not require one to know anything about the PHY layer, or TCP stream reassembly. Maybe not PHY, but you definitionally need to understand TCP, in fact, you have keep-alive and timeout headers that are directly related to TCP. Further more, HTTP/2 is a whole another level of leaky when it comes to HTTP/TCP.