search

thaliproject / thali

Our root repository for all of our projects
MIT License
86 stars 13 forks source link

Figure out what we need to test on Bluetooth limits #240

Closed yaronyg closed 8 years ago

yaronyg commented 9 years ago

We just plain don't know a bunch of things about the limitations of Bluetooth on Android devices. How man simultaneous connections can we have? Incoming? Outgoing? Is there a unified count or a separate count based on direction? What happens if a connection is open but isn't used, will it become a zombie? There are reasons to believe that isn't safe. If we push too hard does the stack fall over?

yaronyg commented 8 years ago

@tompaana you might want to look here this is where I checked in the list of issues with Bluetooth. I think I also sent this to you in email.

yaronyg commented 8 years ago

Does sending and receiving interfere with each other?

yaronyg commented 8 years ago

BTW in the link above I realized I didn't talk about the issue that you brought up in https://github.com/thaliproject/Thali_CordovaPlugin/issues/371 which is that RFCOMM actually support multiple independent multiplexed connections on the single physical connection (e.g. we have multiplexing going on at several levels in our stack :( ). So it is completely possible that if device A connects to device B and then device B decides to connect back that they could both be talking over the same Bluetooth physical connection using the same RFCOMM connection. And yes, in that case, bandwidth would be cut theoretically in 1/2. But in realize the way Bluetooth works is that the master of the Piconet decides how much everyone in the Piconet gets to talk. So if the master isn't fair then the split could be worse. And this will be complicated by the fact that if we are testing many devices at once we could have additional devices in that Piconet (but on different RFCOMM channels) and that would be cut bandwidth further.

In other words a Piconet has a master and I think up to 7 workers for a total of 8 devices. The bandwidth for a single Piconet is, I believe, fixed. So the more workers in the same Piconet the less bandwidth each one is going to get.