CoAP Multicast Requests: Bound Response Collection and Avoid a Reply Flood

Model a multicast CoAP request as a bounded collection of responses from several endpoints. Keep the collection open after the first answer, identify each responder separately, and close it according to an explicit time and resource budget. Silence does not establish that a device is absent or failed.

This guide uses the base multicast behavior in RFC 7252 section 8 over UDP. It does not claim that ordinary unicast retry behavior, DTLS associations, or later group-communication profiles apply unchanged. Record the client and server stack revisions, enabled extensions, multicast scope, responder eligibility policy, and expected group size before qualification. Use an isolated, authorized test network and harmless synthetic resources.

1. Preserve the multicast-specific exchange rules

RFC 7252 requires multicast requests to be Non-confirmable. Responses are sent back by unicast, with the request Token used for matching; the response source is a responder, not the original multicast destination. A multicast GET must not contain an ETag option. See sections 8.1, 8.2, and 8.2.1.

That changes the client’s ownership model. A unicast helper that completes and destroys its request object when one response arrives is unsuitable unless the library has a separate multicast-collection API. Confirm the actual callback lifetime and cancellation behavior rather than modifying packet destination addresses underneath a unicast abstraction.

The Token identifies the collection, not an authenticated device. Retain the responding endpoint alongside each result and apply the deployment’s eligibility and security policy before using it. Do not merge different responders merely because they return equal payloads or happen to choose equal Message IDs.

2. Define the collection record before sending

Field	Purpose
Collection identifier and Token ownership.	Keep callbacks associated with this live collection and prevent reuse while delayed traffic can still match.
Group destination and local interface.	Record the intended scope and distinguish multi-interface experiments.
Responder endpoint and message identity.	Separate peers and apply duplicate handling within the correct endpoint scope.
Requested resource and representation metadata.	Interpret each response in its responder-specific context.
Deadline and late-response policy.	Prevent an endless collection without pretending that the deadline proves completeness.
Maximum responders, bytes, and queued callbacks.	Bound memory and processing work even when many responses arrive together.
Completion reason.	Distinguish deadline reached, caller cancellation, capacity reached, and local error.

Use a collection generation in application bookkeeping so a late callback cannot update a newly allocated object that happens to occupy the same memory. This local safeguard complements protocol matching; it is not a wire-level identity mechanism or permission to reuse Tokens prematurely.

Decide what capacity exhaustion means. A useful result might be “12 eligible responders retained; collection truncated,” with separate duplicate and rejected-response counts. It should not say “12 devices exist.” An overflow flag is part of the result, not a detail hidden in a debug log.

3. Spread replies and bound repeated requests

RFC 7252 recommends a randomized response time within a Leisure interval. The interval should reflect the application and expected load. A server aware of multicast delivery may ignore the request; it must not answer a Non-confirmable multicast request with Reset. See the multicast response and implosion controls.

Qualify the server’s actual delay policy with timestamps from a small controlled group. Do not turn a configured Leisure value into a guaranteed maximum end-to-end latency: scheduling, network delay, and loss remain separate. The client collection window must be chosen with the server policy and the product’s tolerable uncertainty in view.

Rate-limit new group requests at the application level. Sending the same group query immediately after a short collection window can create overlapping response waves. Per-request memory limits alone do not bound the aggregate work from many simultaneously active collections.

Also inspect Message ID allocation. RFC 7252 section 8.1 requires avoiding a multicast Message ID that is still active with a unicast endpoint that might receive the multicast request. A shared allocator or documented library mechanism is preferable to independent application counters that accidentally collide.

4. Build a deterministic multi-responder fixture

1. Configure three synthetic responders with different harmless payloads and controlled response delays. Confirm that all three can appear in one collection.
2. Have two responders use the same response Message ID. Confirm they remain distinct because their endpoint identities differ.
3. Repeat one responder’s message and check that duplicate handling does not inflate the responder count.
4. Delay one response until after the application deadline. Confirm the documented late policy and absence of updates to a later collection.
5. Make one responder silent. Require a partial result, not a fabricated negative response.
6. Set a small responder or byte cap, then exceed it with the fixture. Verify bounded memory and an explicit truncated result.
7. Start overlapping collections at the maximum permitted request rate. Inspect total queued work and callback ownership.

These are proposed tests, not executed network results. Start with a deterministic in-process model where possible, then use a bounded network fixture to observe socket behavior, timers, and queue pressure. Do not conduct an uncontrolled reply-flood experiment on a production network.

5. Interpret responders and missing members correctly

Keep responder-specific resource identities when processing relative links or follow-up requests. RFC 7252 section 8.2 interprets a response using the actual responder’s address in place of the original multicast host. Treating every returned link as belonging to the group can send a later operation to more devices than intended.

If the product needs every commissioned device accounted for, compare the collected set with a separately maintained inventory and use an authorized, bounded per-device reconciliation process. The collection alone cannot distinguish packet loss, sleeping devices, response suppression, or a device that is no longer present.

Do not interpret a response as authorization to trust a claimed device name. The base multicast exchange is not a complete group-security design. Validate the chosen security profile and access controls separately, and avoid using an unauthenticated collection to trigger consequential device actions.

Hypothetical commissioning display

A commissioning tool displays “all devices found” after the first response because its original helper was written for unicast. A controlled three-responder fixture exposes the error immediately: the second and third callbacks arrive after the request object has been closed.

The corrected design owns a bounded collection, shows the completion reason and truncation state, and keeps results indexed by eligible responder. Its release record includes response-delay observations, duplicate cases, capacity limits, and late-callback behavior. That evidence supports a defined collection policy without pretending multicast delivery guarantees a complete census.