How to send `cmsghdr` with SwiftNIO

zaneenders · July 9, 2025, 2:52pm

Hi,

I started writing a Wayland client using SwiftNIO, Mostly following this blog post with the plan of branching out out to ray tracing in one weekend and trying out InlineArray after I get the red square working.

It's been going prettty well but to share memory with Wayland they ask you to send of the file descriptor using sendmsg, cmsghdr . I see referenses to them in SwiftNIO but nothing public. I was wondering if anyone knew how to work around this with SwiftNIO?

Source code from the blog post.

github.com/gaultier/blog

wayland.c

d69a0c75d


      
          
          wayland_current_id++;
          buf_write_u32(msg, &msg_size, sizeof(msg), wayland_current_id);
          
          buf_write_u32(msg, &msg_size, sizeof(msg), state->shm_pool_size);
          
          assert(roundup_4(msg_size) == msg_size);
          
          // Send the file descriptor as ancillary data.
          // UNIX/Macros monstrosities ahead.
          char buf[CMSG_SPACE(sizeof(state->shm_fd))] = "";
          
          struct iovec io = {.iov_base = msg, .iov_len = msg_size};
          struct msghdr socket_msg = {
              .msg_iov = &io,
              .msg_iovlen = 1,
              .msg_control = buf,
              .msg_controllen = sizeof(buf),
          };
          
          struct cmsghdr *cmsg = CMSG_FIRSTHDR(&socket_msg);

Where I am at so far (bad code).

Thanks,
Zane

lukasa · July 10, 2025, 9:33am

This is a cool project Zane, let's see if we can help you bring it to fruition!

Today, NIO never uses sendmsg to issue writes on TCP channels. We do use it for UDP channels, though, which is why you have seen the bindings.

To enable this use-case, then, we need a way for you to optionally "extend" a channel created from a ClientBootstrap (and the child channels from ServerBootstrap) to opt-in to sending objects with metadata.

Achieving this requires several moving pieces, I think:

Defining a new type to represent this "data + control data" object. This would look similar to AddressedEnvelope, but is actually just a struct containing a ByteBuffer and a Metadata type like the AddressedEnvelope metadata. We could even choose to entirely re-use it.
A substantial change to PendingStreamWritesManager that allows the use of sendmsg/recvmsg when using this alternative data-type.
Defining a new ChannelOption that can be used to request a change on the input and output datatypes from the channel. When set, this should flip our I/O functions from read/write/writev to recvmsg/sendmmsg.

As I'm sure you can see, this isn't totally trivial to achieve, but if you're motivated to do it I can help walk you through the various steps.