Re: Text-based IPC for Userspace Implementations

[Guanhao Yin <sopium@mysterious.site>]

Hi,

在 2017年05月16日 21:12, Toke Høiland-Jørgensen 写道:
> "Jason A. Donenfeld" <Jason@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:
https://www.wireguard.io/xplatform/
>>
>> 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
WireGuard.rs.

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