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

[bzbarsky-apple]

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]

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]

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

[ndyck14]

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]

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]

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]

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]

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]

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

[bzbarsky-apple]

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]

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

[stale]

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]

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

[marcelveldt]

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.