class WireWeakSyncClientImpl

Detaches the client end from the controller's lifetime.

After calling `Detach`, closing this client end no longer causes the

filtering state owned by the controller to be removed. The key returned

by the method can be used *once* by a client to reconnect to a detached

controller. This allows clients to ensure the filtering state they

install is resilient to client-side crashes and disconnections. (Note,

however, that closing the client end of the channel *will* flush any

pending changes that have been pushed but not yet committed.)

`Detach` can be called multiple times; the key returned by the most

recent call is valid to reconnect to the controller. Calling `Detach`

will always return a new key and invalidate any previous keys.

Note that, once a client has called `Detach` on a controller, the

controller remains detached even after a reconnection. This means that,

for example, if a client detached, closed the client end, reconnected,

and then closed the client end again, the filtering state owned by the

controller would *not* be removed. After reconnection, the only reason a

client would call `Detach` is to be able to reconnect *again* in the

future, given the key is invalidated after use.

Allocates 48 bytes of message buffer on the stack. No heap allocation necessary.

Registers the specified eBPF program with the sevice.

The program must be verified as a valid socket filter (i.e.

`BPF_PROG_TYPE_SOCKET_FILTER`).

The registration is scoped to this controller. The server keeps the

program registered until the [`fuchsia.ebpf.PROGRAM_DEFUNCT_SIGNAL`]

signal is raised on the program handle or the peer handle is closed.

Matchers installed with this program remain functional even after the

program is unregistered. The caller should keep the peer handle and not

signal [`fuchsia.ebpf.PROGRAM_DEFUNCT_SIGNAL`] until the matchers that

rely on that registration are commited using `Commit()`.

Allocates 32 bytes of response buffer on the stack. Request is heap-allocated.

Append a set of changes to a pending transactional update to the

filtering configuration.

To apply these changes, a client must call `Commit`.

Request is heap-allocated. Response is heap-allocated.

Apply all pending changes. The set of changes will either be applied in

its entirety or, in case of an error, not applied at all.

Allocates 40 bytes of request buffer on the stack. Response is heap-allocated.