Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pandora: implement L2CAP service #322

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

pandora: implement L2CAP service #322

wants to merge 2 commits into from

Conversation

uael
Copy link
Contributor

@uael uael commented Oct 25, 2023

No description provided.

@zxzxwu
Copy link
Collaborator

zxzxwu commented Oct 25, 2023

I really doubt whether Bumble should have such a fine-controlled interface. There is actually no demand to make such an almighty interface...

@uael
Copy link
Contributor Author

uael commented Oct 25, 2023

The issue I'm trying to solve is that we want waiting for incoming connections to be reproducible, while right now it depends on good timing between the link connections and the channel connection request. From a DUT point of view, it's quite hard to make those assumptions and it's almost impossible to implement the Wait API for Fluoride, but from the REF perspective we need maximum control and reproducibility.

Other solutions could be to:

  1. make the l2cap.WaitConnection scoped at the device level instead of connection level and add a l2cap.OwnedBy(channel, connection) API to match channels and connections.
  2. add a l2cap.Register(spec) -> ServerToken API, then modify WaitConnection to take a server token instead of a spec.

Both solutions work but add complexity to the APIs instead of the implementation

@zxzxwu
Copy link
Collaborator

zxzxwu commented Oct 26, 2023

Can we simply add an auto_accept=True argument to create_server() method, and accept() method to channels? Thus, most flow can keep the same.

@uael uael force-pushed the uael/l2cap_pandora branch 5 times, most recently from 3d1d4f0 to 9dbd2d4 Compare November 7, 2023 08:13
In order to avoid any breaking changes this re-impl current APIs with
the exact same behavior.

The previous impl was preventing one to defer the response to an l2cap
channel connection request, both for BR/EDR basic channels and LE credit
based ones. This commit change this to spawn a task on every channel
incoming connection request, then all registered listeners are given a
chance to accept it through a `asyncio.Future`. After a bit of delay, if
none had accepted it, the connection is automatically rejected.
Co-authored-by: Josh Wu <joshwu@google.com>
@uael uael marked this pull request as ready for review November 7, 2023 08:59
@uael uael changed the title WIP: L2CAP Pandora impl pandora: implement L2CAP service Nov 7, 2023
@uael
Copy link
Contributor Author

uael commented Nov 7, 2023

This is a proposed alternative to #320.
It offer more control over the bumble L2CAP layer, but require more structural changes and I'm not sure which path is preferred. Although I think deferred connection accept is a good addition to bumble

@zxzxwu
Copy link
Collaborator

zxzxwu commented Nov 7, 2023

This is a proposed alternative to #320. It offer more control over the bumble L2CAP layer, but require more structural changes and I'm not sure which path is preferred. Although I think deferred connection accept is a good addition to bumble

These features make Bumble over complicated. In fact, if some scenarios require a very complicated control like timing, overwriting the entire L2CAP layer inside the usage is simpler since in Python it's very easy to achieve this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants