MulticastFeed builds CME packets from held messages and recipes and sends them through one configured network feed type. It prepends a PacketHeader containing the supplied packet sequence number and the current UTC sending time. It is the multicast specialization DataFeed<MulticastDelivery>; existing construction and send syntax remains unchanged.
Populate FeedSettings with isolated multicast endpoints. The handler receiving the synthetic data must use matching groups, ports, and network interfaces, and a layout that does not expect a feed the test feed is not configured to send.
Each effective endpoint must contain a canonical IPv4 multicast group, a port in the range 1 through 65535, and an explicit network interface. In a failover layout, the optional secondary endpoint is used only when both its group and port are configured; a partially configured optional secondary endpoint is ignored.
By default, outgoing destinations are restricted to the administratively scoped 239.0.0.0/8 range and the multicast TTL is zero, which confines datagrams to the local host while keeping multicast loopback enabled. An outgoing destination outside 239.0.0.0/8 requires ONIXS_CMEMDH_ALLOW_ANY_MULTICAST_DESTINATION to be enabled. A positive TTL independently requires ONIXS_CMEMDH_ALLOW_MULTICAST_EGRESS to be enabled, so both variables are required when both conditions apply. Each variable accepts 1, true, yes, or on, ignoring case and surrounding whitespace; missing values and all other values leave the corresponding permission disabled.
The feed borrows the ReplayDelayer passed to its constructor, when one is supplied, and therefore must not outlive that policy. MulticastFeed itself is neither copyable nor movable.
Pass a delay of at least one microsecond as the arbitrageDelay constructor argument to enable delayed asynchronous secondary transmission. With the default zero delay, both sides are sent synchronously and ReplayDelayer is not used.
send accepts one or more message holders or reusable recipes. They are placed in one packet in argument order.
The primary transmission is synchronous. With an asynchronous arbitrage delay, the returned Threading::Event becomes ready after the secondary transmission finishes. Always call get when a test must observe delayed-send failures.
The message objects and temporary recipes may be destroyed after send returns. The feed consumes or copies their bytes before returning, even when the secondary send remains pending.
PacketHolder owns a fixed sequence of message holders and can be populated once and sent repeatedly.
The number of messages must be less than MulticastTarget::MaxSpansCount, because the packet header occupies one additional byte span. The complete encoded packet must not exceed FeedSettings::packetMaxSize.
Use sendPrimary or sendSecondary when a test must target one side explicitly. These methods are synchronous and do not apply the arbitrage delay.
If no secondary endpoint is configured, sendSecondary validates the packet and performs no transmission. Mixing sendSecondary with delayed send calls can allow the synchronous secondary packet to overtake queued packets.
Construction throws std::runtime_error when the requested feed or layout is unsupported, or an effective endpoint does not contain a valid IPv4 multicast group, port, and explicit network interface. It throws std::invalid_argument when either multicast authorization described above is required but not enabled. Creating or joining the underlying multicast client can throw other exceptions derived from std::exception, for example when a multicast group or interface is unavailable. A send can throw when the packet is too large, the delayed-send queue is saturated, or a synchronous UDP transmission fails.
Recipe materialization happens before transmission. If any recipe operation throws, no packet is sent. When arguments mix held messages and recipes, the prefixes of held messages materialized before a failing recipe remain committed. Partial mutations are also observable when a caller applies a recipe directly to its own holder with MessageRecipe::applyTo.
For runtime-selected encoded messages, raw datagrams, and custom delivery policies, see Advanced Packet Delivery.