broadcast
Broadcast bytes to all other admitted members.
Best-effort: never throws for an undeliverable frame. A member the transport cannot currently reach — including, on a star, the relaying host itself — is silently skipped, and so is a payload over maxPayloadBytes. Use the roster and the membership events to reason about who is present; do not read a returned Unit as delivery. Deliberately weaker than sendTo, which is addressed and does report.
Reserved leading bytes
The room protocol discriminates its own frames by the payload's first byte, so five values are spoken for — 0x61, 0x63, 0x65, 0x6b, 0x72, ASCII a c e k r (RoomFramePrefix). A raw payload sent here or via sendTo that begins with one of them may be classified as a protocol frame at the far end and never surface on incoming.
The reservation is not uniform, because each family's real classifier differs:
| Byte | Family | What is actually swallowed |
|---|---|---|
0x61 | admit handshake | every payload leading with it |
0x65 | host election | every payload leading with it |
0x72 | host relay | every payload leading with it |
0x63 | channel framing | only payloads of 3 bytes or more |
0x6b | liveness ping/pong | only the literal "kuilt.heartbeat.ping" / "…pong" prefixes |
So a payload leading with 0x6b is not necessarily swallowed — a bare "keepalive" is delivered — but relying on the two conditional rows trades a byte of payload space for a failure mode with no error attached: the classifiers may tighten or widen, and a frame that stops matching simply vanishes. Prefix your own payloads, or send them over a channel view, which frames them for you.