olivedae
commented
9 years ago StubStream for now I believe will open a UDP socket (I.E. representing the underlying Bluetooth hardware) for individual CentralManager's and PeripheralManager's; however, this is likely to introduce a problem. Although a device may run several applications each with their own instance of a CentralManager the device runs over a single L2CAP layer. StubStream will notify the Manager above (a combination of abstractions over the several protocols, handles, and converting incoming data into developer friendly structs) if it receives incoming traffic over the UDP socket (after error handling & logical control stated in the Bluetooth Core Specification) and allow those layers above to handle remaining logic control.
Although this diverges slightly from the Bluetooth paradigm there may be an additional struct created with abstracts information outgoing over the air. As StubStream uses an underlying UDP socket to communicate with other devices (including this one) so will this struct. It may also implement some form of address forwarding/lookup which converts UUIDs into their associated IP address.
The idea behind BluetoothStream (which is to offer an OS specific and trait and interface standard to layers above) seems to be a more suited abstraction for a layer below (possibly the HCI or lower portion of the L2CAP which is exposed by an OS) and to instead restructure BluetoothStream to handle various possible threads/communication with peer L2CAPs, possible segmentation (which goes beyond a Basic L2CAP functionality) and responding to a peer device's in a logical manner without the application having to intervene (I.E. if there was an CommandNotUnderstood returned, BluetoothStream may handle this gracefully).