otPlatDnssdService struct

Registers or updates a service on mDNS. The fields in @p aService follow these rules: - The `mServiceInstance` specifies the service instance label. It is treated as a single DNS name label. It may contain dot `.` character which is allowed in a service instance label. - The `mServiceType` specifies the service type (e.g., "_tst._udp"). It is treated as multiple dot `.` separated labels. It MUST NOT contain the domain name. - The `mHostName` field specifies the host name of the service. MUST NOT contain the domain name. - The `mSubTypeLabels` is an array of strings representing sub-types associated with the service. Each array entry is a sub-type label. The `mSubTypeLabels can be NULL if there is no sub-type. Otherwise, the array length is specified by `mSubTypeLabelsLength`. - The `mTxtData` and `mTxtDataLength` specify the encoded TXT data. The `mTxtData` can be NULL or `mTxtDataLength` can be zero to specify an empty TXT data. In this case mDNS module will use a single zero byte `[ 0 ]` as the TXT data. - The `mPort`, `mWeight`, and `mPriority` specify the service's parameters as specified in DNS SRV record. - The `mTtl` specifies the TTL if non-zero. If zero, the mDNS module will use the default TTL of 120 seconds. - Other fields in @p aService structure are ignored in an `otMdnsRegisterService()` call. This function can be called again for the same `mServiceInstance` and `mServiceType` to update a previously registered service entry, for example, to change the sub-types list, or update any parameter such as port, weight, priority, TTL, or host name. The mDNS module will send announcements for any changed info, e.g., will send "goodbye" announcements for any removed sub-types and announce any newly added sub-types. Regarding the invocation of the @p aCallback, this function behaves in the same way as described in `otMdnsRegisterHost()`.

Unregisters a service on mDNS module. The fields in @p aService follow these rules: - The `mServiceInstance` specifies the service instance label. It is treated as a single DNS name label. It may contain dot `.` character which is allowed in a service instance label. - The `mServiceType` specifies the service type (e.g., "_tst._udp"). It is treated as multiple dot `.` separated labels. It MUST NOT contain the domain name. - Other fields in @p aService structure are ignored in an `otMdnsUnregisterService()` call. If there is no previously registered service with the same name, no action is performed. If there is a previously registered service with the same name, the mDNS module will send "goodbye" announcements for all related records.

Registers or updates a service on the infrastructure network's DNS-SD module. The @p aService and all its contained information (strings and buffers) are only valid during this call. The platform MUST save a copy of the information if it wants to retain the information after returning from this function. The fields in @p aService follow these rules: - The `mServiceInstance` and `mServiceType` fields specify the service instance label and service type name, respectively. They are never NULL. - The `mHostName` field specifies the host name of the service if it is not NULL. Otherwise, if it is NULL, it indicates that this service is for the device itself and leaves the host name selection to DNS-SD platform. - The `mSubTypeLabels` is an array of strings representing sub-types associated with the service. It can be NULL if there are no sub-types. Otherwise, the array length is specified by `mSubTypeLabelsLength`. - The `mTxtData` and `mTxtDataLength` fields specify the encoded TXT data. - The `mPort`, `mWeight`, and `mPriority` fields specify the service's parameters (as specified in DNS SRV record). - The `mTtl` field specifies the TTL if non-zero. If zero, the platform can choose the TTL to use. - The `mInfraIfIndex` field, if non-zero, specifies the infrastructure network interface index to use for this request. If zero, the platform implementation can decided the interface. When the `mHostName` field in @p aService is not NULL (indicating that this registration is on behalf of another host), the OpenThread stack will ensure that `otPlatDnssdRegisterHost()` is also called for the same host before any service registration requests for the same host. Once the registration request is finished, either successfully or failed, the platform reports the outcome by invoking the @p aCallback and passing the same @p aRequestId in the callback. The @p aCallback function pointer can be NULL, which indicates that the OpenThread stack does not need to be notified of the outcome of the request. If the outcome is determined, the platform implementation may invoke the @p aCallback before returning from this function. The OpenThread stack will ensure to handle such a situation. On success, the @p aCallback MUST be called (if non-NULL) with `OT_ERROR_NONE` as the `aError` input parameter. If the registration causes a name conflict on DNS-SD domain (the service instance name is already claimed by another host), the `OT_ERROR_DUPLICATED` error MUST be used. The platform implementation can use other `OT_ERROR` types for other types of errors. The platform implementation MUST not assume that the @p aRequestId used in subsequent requests will be different. OpenThread may reuse the same request ID again for a different request. The OpenThread stack will not register the same service (with no changes) that was registered successfully earlier. Therefore, the platform implementation does not need to check for duplicate/same service and can assume that calls to this function are either registering a new entry or changing some parameter in a previously registered item. As a result, these changes always need to be synced on the infrastructure DNS-SD module. The OpenThread stack does not require the platform implementation to always invoke the @p aCallback function. The OpenThread stack has its own mechanism to time out an aged request with no response. This relaxes the requirement for platform implementations.

Unregisters a service on the infrastructure network's DNS-SD module. The @p aService and all its contained information (strings and buffers) are only valid during this call. The platform MUST save a copy of the information if it wants to retain the information after returning from this function. The fields in @p aService follow these rules: - The `mServiceInstance` and `mServiceType` fields specify the service instance label and service type name, respectively. They are never NULL. - The `mHostName` field specifies the host name of the service if it is not NULL. Otherwise, if it is NULL, it indicates that this service is for the device itself and leaves the host name selection to DNS-SD platform. - The `mInfraIfIndex` field, if non-zero, specifies the infrastructure network interface index to use for this request. If zero, the platform implementation can decided the interface. - The rest of the fields in @p aService structure MUST be ignored in `otPlatDnssdUnregisterService()` call and may be set to zero by the OpenThread stack. Regarding the invocation of the @p aCallback and the reuse of the @p aRequestId, this function follows the same rules as described in `otPlatDnssdRegisterService()`. The OpenThread stack may request the unregistration of a service that was not previously registered, and the platform implementation MUST handle this case. In such a case, the platform can use either `OT_ERROR_NOT_FOUND` to indicate that there was no such registration, or `OT_ERROR_NONE` when invoking the @p aCallback function. The OpenThread stack will handle either case correctly.

Iterates over registered service entries. Requires `OPENTHREAD_CONFIG_MULTICAST_DNS_ENTRY_ITERATION_API_ENABLE`. On success, @p aService is populated with information about the next service . Pointers within the `otMdnsService` structure (like `mServiceType`, `mSubTypeLabels`) remain valid until the next call to any OpenThread stack's public or platform API/callback.