3 ms·

Not a fan of JSON per se for this type of messaging, but I don't think binary parser+validator combinations are that much faster. Plus, this forces C(++) develo

Not a fan of JSON per se for this type of messaging, but I don't think binary parser+validator combinations are that much faster. Plus, this forces C(++) developers to actually validate the data they're exchanging rather than casting raw structs from data buffers, which solves a huge vulnerability. Then again, the lack of 64 bit integers makes the protocol design comically unsuited. I don't think the serialization/deserialisation overhead matters much when also taking into account the bus connection overhead. I would've preferred a better data exchange format but out of all problems I have with Linux IPC, the performance of JSON is the least of my worries.

poettering 2y ago
The 64bit issue is certainly an issue, but very much overblown. First of all, in systemd, which is a heavy D-Bus user, we effectively IRL only send integers > 2^53 when we use UINT64_MAX as a special "niche" marker meaning "unlimited"/"unset"/"undefined". But the thing is that JSON has a proper concept for this: the "null" value (or simply not specifying a specific JSON field). Hence, in reasonably clean APIs this is mostly a non-issue. That said, sd-varlink/sd-json (i.e. systemd's implementation of it), of course is 64bit signed and unsigned integer clean when it processes JSON. More-over it automatically handles if you do what the various specs on the internet suggest you do if you have an integer > 2^53: you encode it as decimal value as a string. Would it be better if JSON would have been more precise on this, yes. Is it a big issue? No, not at all.
- Netch 2y ago
  > if you do what the various specs on the internet suggest you do if you have an integer > 2^53: you encode it as decimal value as a string. Hexadecimal is better - more compact, much less encoding/decoding effort. Alternatively, array of two integers does as well. Text forms for any error, not NaN, are also useful. But issues with non-UTF-8 encodings - as in CJK world - may spoil the picture pretty more.
- accelbred 2y ago
  Are strings used for timestamps? Those are usually why I'm sending 64-bit ints over IPC.
  - Netch 2y ago
    If you want more than 1-second precision, 64 bits are not enough. (Hmm does all C++ std::chrono implementation utilize 128-bit integers for nanosecond precision?)

poettering 2y ago

The 64bit issue is certainly an issue, but very much overblown. First of all, in systemd, which is a heavy D-Bus user, we effectively IRL only send integers > 2^53 when we use UINT64_MAX as a special "niche" marker meaning "unlimited"/"unset"/"undefined". But the thing is that JSON has a proper concept for this: the "null" value (or simply not specifying a specific JSON field). Hence, in reasonably clean APIs this is mostly a non-issue. That said, sd-varlink/sd-json (i.e. systemd's implementation of it), of course is 64bit signed and unsigned integer clean when it processes JSON. More-over it automatically handles if you do what the various specs on the internet suggest you do if you have an integer > 2^53: you encode it as decimal value as a string. Would it be better if JSON would have been more precise on this, yes. Is it a big issue? No, not at all.

Netch 2y ago
> if you do what the various specs on the internet suggest you do if you have an integer > 2^53: you encode it as decimal value as a string. Hexadecimal is better - more compact, much less encoding/decoding effort. Alternatively, array of two integers does as well. Text forms for any error, not NaN, are also useful. But issues with non-UTF-8 encodings - as in CJK world - may spoil the picture pretty more.
accelbred 2y ago
Are strings used for timestamps? Those are usually why I'm sending 64-bit ints over IPC.
- Netch 2y ago
  If you want more than 1-second precision, 64 bits are not enough. (Hmm does all C++ std::chrono implementation utilize 128-bit integers for nanosecond precision?)