Interest in L2CAP comms for android and IOS support?

[tonyage]

I did some exploratory work on my fork to support l2cap socket comms for android and IOS would there be any interest to get this upstreamed?

[twyatt]

Very cool!

It'd be great if you opened a PR. Depending on complexity of the changes, it could take a bit of time/discussion to get it in, but I try to prioritize PRs — so I'd do my best to help get that support integrated.

Or, if the "exploratory work" is in its early stages, also happy to discuss API design and go over some of your code to see how we can get PRs up.

[tonyage]

ok great! I say its exploratory since I've only tested it on a bespoke internal hardware, it is functional though. I would like to put it through the wringer with more generic devices if I get the chance. Changes are fairly self contained, for instance on the android side I added the socket management to BluetoothDeviceAndroidPeripheral a few things for your expectations:

• I've only implemented client side socket connection support, thus far so no Server mode support yet.
• insecure L2CAP channels are fairly robust and usable, secure L2CAP channels however, are a bit cursed (maybe this gets better as non-sdk interfaces are better supported in future android versions). Same experience on my end for IOS
• I think the L2CAP socket logic makes more sense alongside the Connection class logic, but its a bit of chicken and egg situation where Gatt has to be up to retrieve the L2CAP psm from the characteristic.
• connecting to the socket is finicky with the android api, the socket seemingly has 3 states INIT, CONNECTED, and CLOSED. (Android only exposes a bool isConnected for userland state info which isn't great, this will most likely get better as non-sdk interfaces get exposed since they already have L2CAP related types defined). Only recourse I could see here is adding another connectAction member that just awaits with a 2s delay and it typically will connect to an insecure socket with no problems.
• Successful socket connections return a wrapper class that contains the connected socket and the input/output streams
• I intentionally made sockets shortlived so they are closed and disposed of after every read/write operation.
• For I/O, in my use case, I expose a single take(bytes: ByteArray) function that writes data to the output stream and then launches a job to read from the inputstream and using a combination of a coroutine channel as a callback consume data that is streamed from a producer coroutine that actually handles the reading. The function then just emitsAll(callbackChannel) for collection downstream. (Admittedly this flow is hard to manage since it can infinitely emit data depending on device functionality, not sure how to manage this more generically to clean up a collection nicely)

Happy to open a PR when time permits. If you have a contributors style/expectations guide I could reference I would happily take a look. Thanks for you time.

[twyatt]

I've only implemented client side socket connection support, thus far so no Server mode support yet.

Client side only is fine. There have been other requests to have Kable act as a server (#51) but we don't internally have a need so I haven't been unable to prioritize it. It is fine if server implementations come later.

insecure L2CAP channels are fairly robust and usable, secure L2CAP channels however, are a bit cursed (maybe this gets better as non-sdk interfaces are better supported in future android versions). Same experience on my end for IOS

I don't have any experience with L2CAP at all, so unfortunately I won't be able to offer much guidance/help. I'll do my best to research and learn where needed to help though.

I think the L2CAP socket logic makes more sense alongside the Connection class logic, but its a bit of chicken and egg situation where Gatt has to be up to retrieve the L2CAP psm from the characteristic.

I'll have to see some code to get a better understanding of the hurdles you're facing, but chicken-and-egg type of problems felt quite common when building Kable.

connectAction member that just awaits with a 2s delay

Yikes, I had previously read about other delays needed w/ BLE code in Android. I'd like to avoid it, and only use delays as an absolute last resort (if we can't find a more elegant solution).

Successful socket connections return a wrapper class that contains the connected socket and the input/output streams

From a coroutines perspective, flow would be my go-to for a continuous stream of data, but I think there are more specialized solutions that might be better? I wonder if https://github.com/Kotlin/kotlinx-io might offer some nice solutions?

I intentionally made sockets shortlived so they are closed and disposed of after every read/write operation.

Is this typical? If there are use cases that leave it open (for multiple I/O operations) then we'd want to support longer lived sockets in Kable.

I expose a single take(bytes: ByteArray) function that writes data to the output stream and then launches a job to read from the inputstream and using a combination of a coroutine channel as a callback consume data that is streamed from a producer coroutine that actually handles the reading.

I like the simplicity of the take API, the implementation details sound a little complex — the complexity might be necessary, but if/when you put up a PR, I'll see if I can offer some input on ways to simplify it.

Happy to open a PR when time permits.

Ya, that'd be great, but I totally understand being busy. When you have a chance, I'll try to find some time to review it.

If you have a contributors style/expectations guide I could reference I would happily take a look.

There isn't a contributor guide, but generally speaking, it is nice to have some discussion around API design at first. Not a prerequisite though, as some people like to jump right in to code. That is fine by me, if you're willing to potentially have a bit of churn on your PR. As for code style, the linter works pretty well with enforcing styles that I'm accustomed to.

Thanks for you time.

Thank you!!

[twyatt]

Not sure how feasible it would be (depends on how coupled the L2CAP needs to be to the existing BLE implementation in Kable) but if the L2CAP could be implemented as a separate module (maybe call it l2cap) that sits on top of core (i.e. has core as a dependency) then that would be really cool and allow a lot more experimentation — as the module could be documented as experimental but the community could try it out.

By being separate from core means we wouldn't have to worry about breaking existing "core" functionality.

This is all assuming that L2CAP is decoupled enough in Android. 🤞

[tonyage]

It appears to be decoupled enough for this to be the play. The process is:

1. scan for device and pair
2. retrieve the psm (protocol service multiplexer) value from the advertised l2cap characteristic. We can dispose of the peripheral connection after this is done, device only really needs to be paired, but scoping it to the lifecycle of the peripheral is nice.
3. then create socket

Let's do this piece-wise, I'll start with a PR for android support in a new l2cap module and we can see how that goes (I think this might be bloated, but I'll let you decide). Merging the PR might take some time until someone on your end can get their hands on a device to verify functionality since I only have close sourced hardware currently.

I can get started this weekend. Is it cool if I extend the SensorTag app for boilerplate?

[twyatt]

Is it cool if I extend the SensorTag app for boilerplate?

For sure, as long as it doesn't break existing functionality of the sample, then you're welcome to meld it to your needs.

Alternatively, if it does break things, then the L2CAP samples could live on branch(es). 🤷

[9il]

@tonyage I am interested in L2CAP. Could you please share the details or a draft?