This commit enhances the `Srp::Client` "single service mode". This
mode is enabled when a prepared SRP update message exceeds the IPv6
MTU size. In this mode, the client registers its services one by one,
with each SRP update containing only a single service.
The implementation is simplified by changing the `mSingleServiceMode`
flag from a persistent member variable of the `Client` class to a
field within the `MsgInfo` struct, making its scope
message-specific.
State transitions are now correctly applied to host and service
entries when operating in single service mode. This, in turn, helps
ensure that SRP message transaction IDs are managed correctly: the
same ID is used for retries of an unchanged service, while a new ID
is used if the service information has changed.
Finally, a new test case, `TestSrpClientSingleServiceMode`, is added
to `test_srp_server` to cover this behavior and its associated retry
logic in detail.
This commit updates the `MessageQueue` and `PriorityQueue`
implementations to use non-circular doubly linked lists instead of
the previous circular ones. Using a non-circular list requires the
queue to track the head element, but it simplifies common operations
like getting the head and iterating over the messages.
Particularly, `Message::GetNext()` now simply returns the `mNext`
pointer. Previously, `Message` had to store a pointer to its `mQueue`
within its `Metadata` to identify the tail of the queue and stop the
iteration correctly.
This commit also updates the unit tests. In particular,
`test_priority_queue` is significantly enhanced to cover many
scenarios, such as multiple messages with the same priority, and
messages with different priorities being added and removed in various
orders.
This commit updates the SRP client message ID assignment model.
Message IDs are now selected randomly, ensuring they differ from the
last ID used. The same message ID is reused when a message is
retried.
This replaces the earlier design where all messages, including
retries, used sequential message IDs.
The unit test is also updated to validate the new behavior.
This commit modifies `Message::SetPriority()` to prevent changing a
message's priority after it has been enqueued in a `PriorityQueue`.
Attempting to do so will now return `kErrorInvalidState`.
The functionality for altering the priority of an already-enqueued
message is not currently used or required. Should this behavior
become necessary in the future, the recommended approach is to
explicitly dequeue the message first, then change its priority, and
finally re-add it to the queue. This makes the intended behavior
clearer and more explicit within the code.
This commit also updates the `test_priority_queue` unit test to
reflect this change.
This commit introduces the `Dhcp6PdClient` class, which implements
DHCPv6 Prefix Delegation (PD) client functionality. It integrates
with `BorderRouter::RoutingManager` and its `PdPrefixManager`
sub-component. The CMake `OT_BORDER_ROUTING_DHCP6_PD_CLIENT` mapped
to `OPENTHREAD_CONFIG_BORDER_ROUTING_DHCP6_PD_CLIENT_ENABLE` config
enables this feature.
Previously, the platform layer was expected to implement client
functionality, acquiring and providing the delegated prefix(es) to
the OT stack using `otPlatBorderRouter*` callbacks. This approach
continues to be supported. The `Dhcp6PdClient` feature adds native
support for this functionality in the OpenThread core.
The `Dhcp6PdClient` implementation follows RFC 8415, focusing on
prefix delegation and all required behaviors. The client follows the
standard four-message Solicit/Advertise/Request/Reply exchange to
obtain a delegated prefix, followed by a two-message Renew/Reply or
Rebind/Reply exchange to extend the lifetime of the delegated prefix.
When the prefix is no longer needed, a two-message Release/Reply
exchange ends its lease. The current client implementation does not
support the optional "Reconfigure Accept" mechanism.
A set of `otPlatInfraIfDhcp6PdClient*` platform APIs are also
introduced for use by the `Dhcp6PdClient`. These APIs are used to
enable or disable listening for DHCPv6 messages and to handle sending
and receiving them on the standard client and server UDP ports
(546 and 547), effectively acting as a UDP socket.
This commit also includes a comprehensive unit test covering various
aspects of `Dhcp6PdClient`, including common behaviors and many
specific edge cases.
This commit renames DHCPv6-PD related types and methods in
`RoutingManager` to consistently use the `Dhcp6Pd` term.
This commit also updates the related unit test in
`test_routing_manager`. The test is renamed to `TestDhcp6Pd()`, and
the code style is updated to align with other test cases in the same
file. No changes are made to the actual test steps or what is covered
by the test itself. The method for reporting PD prefixes to the
OpenThread stack is modified within the unit test. Instead of using
`otPlat` APIs, `RoutingManager` methods are now directly invoked.
This helps make the unit tests independent of the configuration,
allowing for more flexible models where platform-provided APIs may
not be provided (e.g., DHCPv6 client as part of OpenThread code).
This commit updates the DNS-SD server to support responding to SOA and
NS record queries (including `ANY` record type queries) for the
default service domain. The recommended values for SOA record data
from RFC-8766 section 6.1 are used. The server name included in
SOA/NS answers is derived from the Extended Address of the device,
ensuring it remains fixed and consistent over reboots as long as the
device's Extended Address stays the same.
A new detailed test case is added in the `test_dns_client` unit test
to cover all the newly added behavior.
Currently, if the platform has no upstream DNS server configured,
upstream DNS query will eventually time out. This can lead to delays
in responding to the DNS client.
The new otPlatDnsIsUpstreamQueryAvailable API provides a mechanism for
the platform to proactively signal the unavailability of upstream DNS.
This commit updates the DNSSD server/resolver to ensure it includes
the questions in the response message when the returned RCODE is
`NameError` (NXDOMAIN). It also clears the question count and any
partially appended content if there is a failure to append all
questions (when `kResponseServerFailure` (SERVFAIL) is returned).
It also adds a test case in `test_dns_client` to resolve a
non-existent name and validate the included questions.
This commit updates `BorderAgent` modules to directly manage the
registration of mDNS MeshCoP services. Previously, this was the
responsibility of the platform or higher-level code. This behavior is
enabled using `OPENTHREAD_CONFIG_BORDER_AGENT_MESHCOP_SERVICE_ENABLE`
configuration option.
When enabled, the `BorderAgent` module itself will register the
`_meshcop._udp` service name with properly formatted TXT data. As the
state changes, the service registration is updated accordingly.
If the ephemeral key feature is enabled and used, the `BorderAgent`
will also manage the registration of the `_meshcop-e._udp` service.
The implementation allows the service instance name to be configured
in different ways. The Thread specification recommends using a
user-friendly name, such as "<VendorName> <ProductName>". The
name can be set using a newly added configuration option, or
alternatively, using a newly added public API for projects where the
name needs to be set at run-time after device initialization.
This commit also updates `test_border_agent`, validating all the
newly added behaviors related to MeshCoP service registrations.
This commit updates the mDNS service registration to allow services
for the local host. The `mHostName` field in an `otMdnsService`
structure can now be set to `NULL` to indicate that the service
if for the local host.
The `test_mdns` unit test is also updated to verify this new
functionality.
This commit updates the DNS-SD `Server` implementation to support
queries for the `ANY` record type. This is supported whether a query
is resolved using the SRP server or the OpenThread native Discovery
Proxy.
When a query is resolved using the SRP server database, all known
records that match the query name and type are included in the
response (e.g., AAAA and KEY records for a hostname; SRV, TXT and
KEY records for a service instance name; and PTR records for service
type or sub-type query names).
Note that unlike mDNS, where an `ANY` query is expected to elicit all
known matching records, in the case of a unicast DNS query for `ANY`,
the response is only required to contain at least one matching
record, not necessarily all of them. This will be the behavior when
the Discovery Proxy is used to resolve a unicast DNS `ANY` query
(i.e., once the first answer is received from the Discovery Proxy
(mDNS), a response is prepared and sent to the client).
The unit tests `test_dns_client` and `test_dnssd_discovery_proxy` are
updated to validate the new `ANY` query behavior.
This commit adds implementation for RDATA translation in the
OpenThread native discovery proxy. Specifically, for certain record
types (like CNAME) where the record data includes one or more
embedded DNS names, this translation applies. If the embedded DNS
name in RDATA uses the local mDNS domain (`local.`), it is replaced
with the corresponding domain name for the Thread mesh network
(`default.service.arpa.`). Otherwise, the name is included unchanged
in the record data.
A new method, `AppendTranslatedRecordDataTo()`, is added to perform
this translation. It utilizes the `DataRecipe` table, similar to
`DecompressRecordData()`, to parse the record data and update the
embedded DNS names as needed.
The `test_dnssd_discovery_proxy` unit test is updated to cover the new
record data translation behavior.
This commit enhances the OpenThread DNSSD name server/resolver and its
native Discovery Proxy to support queries for arbitrary record
types.
To enable this, a new set of `otPlatDnssd` APIs are introduced for
generic `RecordQuerier`. These APIs mirror the existing APIs in the
OpenThread native mDNS module, allowing direct use of the native mDNS
implementation.
The discovery proxy implementation is updated to start and stop the
mDNS `RecordQuerier` when receiving a query for an arbitrary record
type, passing the first response record back to the client.
The unit tests `test_dnssd_discovery_proxy` and `test_dns_client`
are updated to cover all the newly added behaviors in discovery proxy.
This commit updates the mDNS `RecordQuerier` to handle record types
where the RDATA contains one or more potentially compressed DNS
names. For these types, the reported record data is now decompressed
to include the full DNS names. This enhancement applies to the
following record types: NS, CNAME, SOA, PTR, MX, RP, AFSDB, RT, PX,
SRV, KX, DNAME, and NSEC.
To achieve this, a helper `ResourceRecord::DecompressRecordData()`
method is introduced. This method uses a "recipe" formula specific
to each supported record type. The recipe defines the number of
prefix bytes before the first embedded name, the number of DNS
names, and the minimum number of suffix bytes after the names. A
common implementation then uses this recipe to parse and decompress
the RDATA. This approach makes the implementation flexible and allows
for easier addition of new record types and formats in the future.
Unit test `test_dns` is updated to validate the newly added method.
This commit refactors the `Mle` modules and combines the `MleRouter`
and `Mle` classes into a single `Mle` class which now handles both
FTD and MTD functionalities.
The `MleRouter` and `Mle` classes were originally intended as
sub-classes, where the base class `Mle` would provide MTD and common
behaviors, and `MleRouter` would implement FTD-specific behaviors.
However, over the years and as new features were implemented, these
two classes became more intertwined, and the `Mle` class began to
include many FTD-related functions and interactions with `MleRouter`
private variables and methods.
This commit simplifies the code by combining the two into a single
class. The previous `mle_router.cpp` file is also renamed to
`mle_ftd.cpp` to indicate that it implements FTD-specific MLE
behaviors.
This commit introduces an API to iterate over the local host IPv6 and
IPv4 addresses known to the OpenThread mDNS module.
The platform layer is responsible for monitoring and reporting all
host IPv4 and IPv6 addresses to the OpenThread mDNS module, which
then tracks the full address list
(see `otPlatMdnsHandleHostAddressEvent()`). The newly added function
allows iteration through this tracked list, primarily intended for
information and debugging purposes.
This commit also adds a CLI command to utilize the new API.
Additionally, the `test_mdns` unit test has been updated to validate
the functionality of the newly added API.
This commit introduces an alternate mechanism for the platform layer
to signal local host address changes to the OpenThread mDNS module.
The existing approach, where the platform invokes
`otPlatMdnsHandleHostAddressEvent()` for each added or removed
address, remains supported.
The new approach allows the platform to call the newly added
`otPlatMdnsHandleHostAddressRemoveAll()` callback once, immediately
followed by invoking `otPlatMdnsHandleHostAddressEvent` for every
currently assigned IPv4 and IPv6 address on the interface.
These two approaches offer flexibility for platforms with varying
capabilities accommodating different operating systems and network
stacks. Some network stacks may provide mechanisms to identify the
added or removed addresses, while others may only provide the new
list upon a change.
The `test_mdns` unit test is updated to validate this newly added
mechanism.
This commit introduces a new mechanism in `RoutingManager` to
configure OMR prefix handling on a Border Router. This provides
manual administration options to explicitly set a custom OMR prefix
or disable it, in addition to the existing default behavior where the
BR automatically selects and manages the OMR prefix. These new
administrative configurations can also be used during testing,
particularly for certification tests.
This commit adds new public OpenThread APIs and a CLI command,
`br omrconfig`, for this functionality. Notably, the new APIs allow
updating the OMR configuration while the BR is enabled and running,
and the implementation correctly adjusts to the new requested
behavior.
A new detailed test case is added to the `test_routing_manager` unit
test, covering the new behavior.
This commit enhances the native OpenThread mDNS implementation to
streamline the registration of the local host and its IPv6/IPv4
addresses.
Previously, registering the local host required tracking host
addresses and using `otMdnsRegisterHost()`, similar to registering
any other host. This commit introduces a simpler alternative that
handles both IPv6 and IPv4 addresses.
The changes in this PR include:
- The local host name can be explicitly set by the caller using new
API `otMdnsSetLocalHostName`. However, if not provided, the mDNS
module automatically generates a name derived from the device's
Extended MAC address.
- A new platform API callback, `otPlatMdnsHandleHostAddressEvent`, is
introduced to notify the OpenThread mDNS module of host address
changes.
- The OpenThread mDNS maintains an internal list of host addresses,
automatically updating it based on platform callbacks. A short
guard time is used to group multiple changes before announcing
them. Transient changes (e.g., address removal and re-addition) are
handled to prevent unnecessary announcements.
- Host IPv4 addresses (A records) are now supported. The `HostEntry`
class is updated to optionally include IPv4 addresses, in addition
to the required IPv6 addresses.
- A detailed test case in `test_mdns` covers all new local
host-related behaviors.
This commit enhances `RecordQuerier` to support queries for the ANY
record type. When querying for ANY, the response may contain various
record types. The implementation ensures that these different types
are cached separately and correctly handles responses containing
multiple record types (with or without "cache-flush" flag).
The `test_mdns` unit test is updated to validate this new behavior in
detail.
This commit introduces new Spinel properties to support CLI service in
NCP.
* Added `SPINEL_PROP_STREAM_CLI` property: This streaming property
provides a bidirectional channel for interacting with the NCP's
command-line interface (CLI). The host can send CLI commands to the
NCP by setting this property. The NCP will then execute the
commands. The NCP will send the output of the executed command (if
any) back to the host via unsolicited notifications of this same
property.
This commit enhances the native mDNS implementation by adding
`RecordQuerier`, which enables continuous queries for arbitrary
record types and query names. The `RecordQuerier` follows a pattern
similar to service/address browsers and resolvers, allowing multiple
queriers to be started for the same record type and name (provided
they use different callbacks).
Record results are cached, and the cache correctly handles and reports
when new records are added or removed (either explicitly or due to
timeouts), including when the "cache-flush" flag is used in a
response.
Public OpenThread APIs and corresponding CLI commands are added for
`RecordQuerier` functionality.
The `test_mdns` unit test is updated with a detailed test case
covering the newly added `RecordQuerier` functions.
This commit introduces a mechanism in `RoutingManager` to parse and
process Recursive DNS Server (RDNSS) options within received Router
Advertisement (RA) messages. The list of discovered RDNSS addresses
is tracked (per router) by `RoutingManager`, applying the advertised
lifetime to properly age the discovered entries.
This commit adds a new public API to retrieve the list of tracked
RDNSS addresses, along with a callback mechanism where OpenThread
users can register to be notified of changes to the RDNSS list. This
callback is invoked when any of the following changes occur:
- A new RDNSS address is advertised by a router.
- A previously discovered address is removed due to the router
advertising it with a zero lifetime.
- A previously discovered address has aged out (its lifetime expired
without being re-advertised).
- `RoutingManager` determines that the router advertising the address
is now unreachable, resulting in the removal of all its associated
entries.
This commit also adds corresponding CLI commands for the new API.
Furthermore, `test_routing_manager` is updated to include a test case
covering all the newly added behaviors in detail.
This commit updates the `Srp::Server` so that Fast Start Mode can be
disabled by a call to `otSrpServerSetAutoEnableMode()`, in addition
to the existing method of calling `otSrpServerSetEnabled()`.
The `test_srp_server` unit test is updated to validate this new
behavior.
This commit adds "Fast Start Mode" feature for SRP server. This
feature is designed for scenarios where a device, often a mobile
device, needs to act as a provisional SRP server (e.g., functioning
as a temporary Border Router). The SRP server function is enabled
only if no other Border Routers are already providing the SRP
service within the Thread network. A common use case is a mobile
device joining a Thread network where it may be the first, or only,
BR. Importantly, Fast Start Mode allows the device to quickly start
its SRP server functionality upon joining the network, allowing other
Thread devices to quickly connect and register their services without
the typical delays associated with standard Border Router
initialization and SRP server startup (using NetData Publisher).
This commit adds a new option in `otSrpServerAddressMode` as
`OT_SRP_SERVER_ADDRESS_MODE_UNICAST_FORCE_ADD`. This allows faster
SRP server start up by bypassing the Network Data publisher and
adding the "SRP/DNS unicast" entry directly to Network Data upon enabling
of the SRP server, regardless of how many other similar entries are
present.
This option is intended for testing and specific situations. A warning
is added to indicate that using this option will make the device
non-compliant with the Thread specification.
The unit test `test_srp_server` is updated with a new test case to
validate the new `AddressMode` and its related behavior.
This commit updates `kAloc16ServiceEnd` to `0xfc1f`, aligning it with
recent changes in the Thread specification. The range `0xfc10-0xfc1f`
is now used for service ALOC16 corresponding to the 16 service IDs,
and the range `0xfc20-0xfc2f` is reserved for future use.
It also updates the `NetworkData::Leader::AnycastLookup()` to
explicitly check a given `aAloc16` against the defined ALOC16 ranges.
This replaces the previous model, which assumed that ALOC16 ranges
followed each other sequentially. While this assumption held true
previously, the introduction of the reserved range disrupts this
pattern. The explicit range check ensures correct behavior regardless
of future changes, making it a safer and more robust approach.
This commit enhances `NetworkData` modules to skip invalid TLVs during
iteration or search operations. Specifically, `NetworkDataTlv::Find
()` and `NetworkData::Iterate()` are updated. These two methods are
the primary methods used by all other methods for parsing or
searching for TLVs.
Generally, the leader validates TLVs before registration using
`NetworkData::Leader::Validate()`. However, this change improves
robustness by allowing receivers to also handle possible malformed
Network Data.
This commit also updates the `test_network_data` unit test to cover
the new behavior of skipping invalid TLVs.
This commit updates and enhances the CRC module.
It updates the implementation to allow both CRC16 and CRC32
calculation with different polynomials. It adds new `Feed()` methods
to add bytes from a buffer or from a message into CRC computation. It
also adds a unit test to cover CRC calculation (both CRC16 and
CRC32).
This commit updates `LinkQualityInfo` to track the "link quality out,"
which is the link quality from the neighbor's perspective. This value
is currently tracked by the `Router` class. The existing methods in
`LinkQualityInfo` that return the "link quality in" are renamed to
use `LinkQualityIn` to clarify and distinguish them.
This change uses existing bits in `LinkQualityInfo`, freeing up bit
fields in the `Router` class to be used for other information.
This commit adds `Tasklet::Unpost()` to remove a tasklet from the
tasklet scheduler run queue if previously posted.
It also adds a detailed unit test, `test_tasklet`, covering various
uses of `Tasklet`, such as posting single or multiple tasks.,
re-posting a task from its own handler, Un-posting tasks in different
orders.
This commit adds a version field (`uint8_t`) to DNS/SRP Anycast and
Unicast Service entries in `NetworkData::Service::Manager`.
For Unicast entries, the version the version field is placed after
the existing fields, specifically after the IPv6 address and port number fields.
For Anycast entries it is added as the in server data as part of the
Server TLV.
When processing Network Data service entries, the version field is
optional and if absent, version number zero is assumed.
The `NetworkData::Publisher` now considers entries with the same or
higher version number when deciding whether to add or remove its own
entry, preferring those with a higher version.
In SRP client, when `AutoStart` mode is used and if there are multiple
Unicast, Service entries, the client prefers the one with larger
version number.
When selecting an anycast entry, the existing rules regarding sequence
numbers are still used. If multiple entries with the same sequence
number exist, the client will assume the minimum version number among
all such entries.
This commit also updates the `test_network_data` unit test, validating
the new format and related methods.
`test_netdata_publisher.py` is also updated to check service entries
with different version numbers.
This commit updates `LinkedList` and `OwningList` to enhance
`FindMatching()`, `RemoveMatching()`, and related methods to use
`Matches()` with a variable number of arguments. The implementation
uses a variadic template function and forwarding references.
This commit introduces a new mechanism for the TREL link to detect and
handle discrepancies between the IPv6 address and port used by a TREL
peer in a received TREL packet, and the information previously
reported by the platform layer (through DNS-SD discovery) for the
same peer.
Ideally, the platform underlying DNS-SD should detect changes to
advertised ports and addresses by peers. However, there are
situations where this is not detected reliably.
As a received frame over the TREL radio link is processed by the MAC
or MLE layers, if the frame passes receive security checks at either
layer (indicating it is a secure and authenticated/fresh frame from a
valid neighbor), the TREL peer socket address is automatically
updated from the received TREL packet info. This ensures the TREL
peer table is updated correctly if there are changes to TREL peer
addresses of valid Thread neighbors upon rx from such neighbor,
increasing the robustness of the TREL link.
This commit also introduces a new `otPlatTrel` platform API,
`otPlatTrelNotifyPeerSocketAddressDifference()`. The TREL
implementation now notifies the platform layer whenever it detects a
discrepancy in a TREL peer's socket address, regardless of whether
the peer table is automatically updated. This allows the platform
layer to take any appropriate action, such as restarting or
confirming DNS-SD service resolution query for the peer service
instance and/or address resolution query for its associated host
name.
This commit also adds a new test that validates the newly added
behavior, including the auto-update of peer table information and
notification of the platform through the new API, triggered by either
MLE or MAC messages over the TREL radio link.
This commit contains the following changes to `LinkedList`:
- Removes the `FindMatching()` version that searches within a given
sub-section of the list, as this method is no longer needed.
- Renames the method that finds a matching entry and also returns the
`prev` entry in the list to `FindMatchingWithPrev()`. This
distinguishes it from other `FindMatching()` overloads and
clarifies its purpose. This method is often used when the caller
wants to find the matching entry and later remove it from the list.
This commit updates `Srp::Server` to associate its UDP socket with
`kNetifThreadInternal`, ensuring that received messages are from the
internal Thread network interface (i.e., from devices within the
Thread mesh).
This commit introduces `kNetifThreadInternal` as a network interface
option for UDP sockets. Unlike other options, this disallows the use
of platform UDP for the socket, indicating that the socket should use
the OpenThread internal Thread network interface only.
This model replaces the previous approach where `ShouldUsePlatformUdp()`
would check the socket port against a set of port numbers used by
different modules (such as MLE, TMF, Joiner Router, etc) to determine
whether platform UDP APIs should be used. With the new model, each
module decides whether to associate its socket with the
`kNetifThreadInternal`.
This is a more flexible and extensible model, ensuring that sockets
that should not use the platform do not waste resources (they will
not be created or opened/closed on the platform). This also help
avoid edge cases where platform UDP operations may unintentionally
fail when the platform socket is not actually needed.
This commit updates how address lists are compared in the unit test
`spinel_prop_codec`, ensuring that the correct size based on the
array length is passed to `memcmp()`.
This commit updates how the `NetifId` is set on a `Udp::Socket`. It is
now specified as a parameter in the `Open()` call instead of `Bind()`.
This change makes the socket more flexible by allowing the `NetifId`
to be known earlier (which can be used for future optimizations). It
also allows the desired `NetifId` to be set even when `Bind()` is not
explicitly called, such as when `Connect()` or `SendTo()` are used on
a socket that is not yet bound. Previously, `kNetifThread` was
assumed by default in these situations.
The public `otUdp` APIs are left unchanged to ensure backward
compatibility.
When the ot-rcp enters the assert state, the host crashes and exits.
But the ot-rcp still runs in the dead loop and becomes an orphan
process.
This commit enables the platform assert so that the ot-rcp can
automatically exit when entering the assert state.
This commit fixes an issue in spinel_prop_codec unit test.
We cannot use Spinel::Decoder::ReadUintPacked with a spinel_prop_key_t
type. This will cause build errors on arm platforms.
This commit adds spinel_prop_codec module to lib/spinel to provide
encoding & decoding functions for complex spinel properties.
This commit moves the encoding of `SPINEL_PROP_DNSSD_HOST`,
`SPINEL_PROP_DNSSD_SERVICE` and `SPINEL_PROP_DNSSD_KEY_RECORD` from
NcpBase to the lib and adds the decoding functions. The background is
that I found the encoding & decoding of complex spinel properties are
error-prone. However the encoding and decoding of one property are
usually put in different places. For example, encoding is in
openthread ncp while decoding is in ot-br-posix ncp spinel. It's
difficult to debug the decoding in ot-br-posix and there is no unit
tests for the encoding & decoding.
This commit puts the encoding & decoding together and adds unit tests
to ensure they are correct.
This commit implements response aggregation (RFC 6762 section 6.4) in
the mDNS module. If multiple responses are scheduled to be sent, each
delayed by a different interval, earlier responses are further
delayed to allow aggregation with other responses scheduled to go out
a little later.
Before preparing a response, we determine the next multicast
transmission time that is explicitly after the current time. This is
used for response aggregation. As the response is being prepared,
different entries can decide whether to extend their answer delay
duration if allowed (e.g., probe question answer delay cannot be
extended) and possible (not extending the delay beyond the maximum
allowed delay).
To realize this, the way we track the `AnswerTime` of records is
changed. It is now tracked by two variables: `mQueryRxTime`
(the receive time of the question triggering the answer) and
`mAnswerDelay`.
This commit also adds `TestResponseAggregation()` to the `test_mdns`
unit test to validate the response aggregation behavior.
This commit implements ncp version of otPlatDnssdRegisterHost.
1. move the position of `SPINEL_PROP_DNSSD_STATE` in `spinel.h`
because it was by mistake put within the range of
`SPINEL_PROP_SRP_SERVER`. The value is unchanged.
2. A template method `DnssdUpdate` is added because the same process
works also for DNSSD service and key record which will be added in
following PRs.
Abtin Keshavarzian