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

Support some sort of setup where we browse for operational advertisements and act on them #25091

Open
bzbarsky-apple opened this issue Feb 15, 2023 · 13 comments
Labels

Comments

@bzbarsky-apple
Copy link
Contributor

We could browse for _matter._tcp and if a new instance name appears possibly act on it by, for example:

  1. Retriggering any pending resubscribe attempts to the given node id.
  2. Notifying higher layers that the node id is now visible.
  3. What else?

Not clear, if we do this, whether this should live in the core SDK, or the Darwin framework, or somewhere else.

In practical terms, right now we do not have a way to "browse without doing a resolve" in the core SDK, though the Darwin framework could do this pretty easily.

We also do not have a "stop a single resolve for the given browse", so we would need to think about the resolve lifetimes here a bit if we do this inside the core SDK.

@jtung-apple @woody-apple @vivien-apple @ndyck14

@ndyck14
Copy link

ndyck14 commented Feb 21, 2023

probably a derivative of case number 2, but this should also minimize commissioning time as there will not be an exclusive need to poll for operational records after sending operational credentials over BLE

@bzbarsky-apple
Copy link
Contributor Author

In practice, the commissioning bits will not know about the browse; the only thing the browse might help is cache the data....

@ndyck14
Copy link

ndyck14 commented Feb 24, 2023

what i mean is:

  1. PASE over BLE
  2. Send operational cred
  3. Start browse
  4. Resolve address immediately on DNS adv leading into CASE

Right now, SDK will poll to resolve. Admins can optimize that poll/backoff to minimize unnecessary delays, but DNS advs (e.g. browsing) will effectively give callbacks.

@bzbarsky-apple
Copy link
Contributor Author

The browse will just give us the instance name. We already know the instance name... I guess the key part is that we don't have to guess when to start the resolve and how long to keep it up for.

That would take some pretty significant reorganization of the core SDK bits to do, though. But yes, might be possible in a followup.

@andy31415
Copy link
Contributor

minmdns would also receive all "boot broadcast" packets, so it would know of any newly rebooted operational devices.

I believe any specific processing for this should not be limited for darwin but should be based on capabilities of the mdns stack and it sounds like minmdns and darwin could be configured to allow for continous monitoring (and I imagine avahi can have an equivalent logic)

@bzbarsky-apple
Copy link
Contributor Author

bzbarsky-apple commented Feb 28, 2023

I believe any specific processing for this should not be limited for darwin

The current SDK "browse" APIs do not allow the necessary processing to take place in a sane way. See this part from the original issue comment:

We also do not have a "stop a single resolve for the given browse", so we would need to think about the resolve lifetimes here a bit if we do this inside the core SDK.

Note that #25317 is not claiming to resolve this, precisely because it's Darwin-only. If we redesign our dns-sd abstraction to allow what that PR does, that would be ideal, obviously.

@andy31415
Copy link
Contributor

I think the key here may be actual usage - where within the SDK will this be used and how? If this is an SDK API, it should probably have some form of API surface with platforms not supporting just saying E_NOT_IMPLEMENTED.

As it stands for #25317 it seems to add an API without actual usage in any example or SDK functionality.

@andy31415
Copy link
Contributor

I think this would be valuable in ICD, where we could resume subscriptions upon being notified of some operational node appearance.

@bzbarsky-apple
Copy link
Contributor Author

where within the SDK will this be used and how?

In full generality? It would be used for subscription retriggering, but also possibly to notify applications that now is a good time to send commands, etc.

@woody-apple woody-apple added v1.2 and removed darwin labels Apr 4, 2023
@woody-apple
Copy link
Contributor

Removing darwin label, given it's done at that level. Core SDK issue to consider at this point.

@woody-apple woody-apple changed the title Consider some sort of setup where we browse for operational advertisements and act on them Support some sort of setup where we browse for operational advertisements and act on them Apr 4, 2023
@stale
Copy link

stale bot commented Oct 15, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@s-mcclain
Copy link
Contributor

Is there any traction on getting this support added? We're interested in similar functionality here as well.

@marcelveldt
Copy link
Contributor

We are interested in this as well. We have just implemented our own mdns discovery to get the operational nodes but it feels kind of dumb that we're all reinventing the wheel now. I'm particular struggling with the detection of restarted nodes.

Either use a short subscription ceiling and (ab)use that as a aliveness detection or use a high subscription ceiling and detect the node re-registering over mdns.

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

No branches or pull requests

6 participants