Text-based IPC for Userspace Implementations

Guanhao Yin sopium at mysterious.site
Tue May 16 18:33:43 CEST 2017


在 2017年05月16日 21:12, Toke Høiland-Jørgensen 写道:
> "Jason A. Donenfeld" <Jason at zx2c4.com> writes:
>> Hey guys,
>> Currently wg(8) talks to the kernel by passing structs through an
>> ioctl. Due to upstream demands, this is going to be changed to
>> netlink, and we'll ditch those structs. wg(8) previously tried to
>> re-use those same structs for userspace implementations, passing them
>> through a unix socket. Implementors did not like dealing with this.
>> Since the structs are going for the kernel stuff, we might as well
>> move to something better, too, for the userspace stuff. Therefore
>> wg(8) now has a very simple text-based IPC format over unix sockets
>> (or Windows named pipes) that can be easily implemented in nearly
>> every language, even bash.
>> I've written a small description of it here:
>> This will be part of the next snapshot.
>> Any questions?

Good! 😄.

In the “configuration protocol” section, I think “wg(8) responds to
...” should be “An userspace implementation respondes to ...”?

A text based format is certainly easier to deal with than C
structs. Hope I can find some time to finally implement it in

That said, I still like the idea that an userspace implementation
being usable without wg(8): it just takes a configuration and runs it,
simple and straightforward.

> I applaud the general idea of moving to a text-based interface. But why
> invent Yet Another Configuration Format?
> I guess you could say that key=value pairs are fairly straight forward;
> but from the examples it looks like there's an implicit nested
> structure? I.e. a public_key=xxx line denotes the start of a new
> endpoint, and the following keys are logically part of that endpoint?
> Or? If this is the case, you'll need a stateful parser to parse it,
> which is not immediately obvious from the description, and is bound to
> trip people up at some point...
> So why not avoid any possible confusion and just emit JSON? Or another
> well-established serialisation format where the nesting can be made
> explicit... :)

+1 for well-established serialisation format.

Guanhao Yin

More information about the WireGuard mailing list