JSONRPC2 over TCP: JSON splitting, etc.

[Basile Starynkevitch]

Hello list,

I (Basile Starynkevitch) am the main developer of GCC MELT a plugin and lispy domain specific language -translated to C++ suitable inside GCC- to customize and extend the GCC compiler. (Both MELT and GCC are free software GPLv3 licensed, FSF copyrighted).

I am adding JSONRPC2 client abilities to MELT. The main motivation would be to communicate with the future MELT monitor (a server providing a web interface and persistency to MELT; this is work in progress, pre-alpha stage, see melt-monitor -also GPLv3 free software on github).

(I'm not willing to use existing implementations, first to avoid an additional dependencies, and mostly because MELT has its own garbage collector and runtime system).

However, JSONRPC2 abilities are useful on their own , and I believe some people might be happy to use MELT new JSONRPC2 client abilities to some other external JSONRPC2 server.

I want to avoid HTTP transport, because in practice that would require depending on some additional HTTP client library

So I have several questions related to JSONRPC2 (I am a newbie on that subject), after reading http://www.simple-is-better.org/json-rpc/extension_transport.html  . Of course, I'm mostly interested by GPLv3 compatible free software implementations running on Linux.

• In the JSONRPC protocol, I guess that the order of field in JSON objects is not signficant. So an implementation can send (on the client side)

  

    {"jsonrpc": "2.0", "method": "sum", "params": [3, 4], "id": "1"}

but it could also send

     {"id":"1","jsonrpc":"2.0","method":"sum","params":[3,4]}

is this correct? Likewise is the order of fields in the reply significant? I believe that no!

• Are there any server implementation using Unix (technically AF_UNIX) sockets?

• Are there any implementation of JSONRPC2 on sockets using JSON splitting?

• I understand that JSON splitting means putting several JSON objects immediately one after the other without any spaces between closing brace and next request opening brace, e.g.

    {"jsonrpc":"2.0","method":"sum","params":[3,4],"id":"1"}{"jsonrpc":"2.0","method":"sum","params":[5,6],"id":"2"}

which I am trying to implement but which suprises me. I would find easier if the specification said that the client MUST put at least one space between them.

• can a JSONRPC2 server implementation insert a newline at the end of each reply JSON object? (in a JSON splitting implementation) My understanding  is that yes?

• Is it sensible (at least as an extension) to enable JSONRPC in both directions once a socket connection is established?

Thanks for reading. Regards.

--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[Shane Green]

Correct, the order of fields in a JSON object is irrelevant as the representation is that of an unordered key/value hash.  Only lists, enclosed by brackets, are ordered.  

It’s generally considered best practice to have each connection dedicated to either sending or receiving requests, not both.  This way incoming messages don’t need to be inspected to determine whether they are requests or responses.  The specification likely does not specify that this is a requirement and such usage would still be viable JSON-RPC, it’s just not the typical integration pattern for most solutions.  

--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to json-rpc+u...@googlegroups.com.
To post to this group, send email to json...@googlegroups.com.
Visit this group at http://groups.google.com/group/json-rpc.
For more options, visit https://groups.google.com/d/optout.

[Michal Jezek]

Hi Basile,

Partial answer, inline:

In the JSONRPC protocol, I guess that the order of field in JSON objects is not signficant. So an implementation can send (on the client side)  

    {"jsonrpc": "2.0", "method": "sum", "params": [3, 4], "id": "1"}

but it could also send

     {"id":"1","jsonrpc":"2.0","method":"sum","params":[3,4]}

is this correct? Likewise is the order of fields in the reply significant? I believe that no!

Correct, order is not significant, both request and response.

• Are there any server implementation using Unix (technically AF_UNIX) sockets?

• Are there any implementation of JSONRPC2 on sockets using JSON splitting?

Don't know, sorry.

• I understand that JSON splitting means putting several JSON objects immediately one after the other without any spaces between closing brace and next request opening brace, e.g.

    {"jsonrpc":"2.0","method":"sum","params":[3,4],"id":"1"}{"jsonrpc":"2.0","method":"sum","params":[5,6],"id":"2"}

which I am trying to implement but which suprises me. I would find easier if the specification said that the client MUST put at least one space between them.

I admit I haven't heard of "JSON splitting" in this sense, but let me answer anyway:
Transport issue, not specified by JSON-RPC2 itself. For your application you can replace HTTP transport with your one which specifies just a space between objects. IMHO a general socket implementation without such an extra requirement would be better.

• can a JSONRPC2 server implementation insert a newline at the end of each reply JSON object? (in a JSON splitting implementation) My understanding  is that yes?

Transport issue, up to you. General advice is "be strict in what you send (which could mean no extra chars, but I'd personally consider an extra whitespace absolutely OK), and be generous in what you accept (ignore and don't require whitespace between objects).
Notice that the same advice applies inside requests/responses (your peer may send whitespace, e.g. after commas).

• Is it sensible (at least as an extension) to enable JSONRPC in both directions once a socket connection is established?

Yes. Why not. Not an extension I think.

Kind regards,
Michal

-- 
       /////////
      ///////////
 __oo' ///////////
a ___  ///////////
      ^^      ^^

[Alex Efros]

Hi!

On Mon, Jul 21, 2014 at 02:05:22AM -0700, Basile Starynkevitch wrote:
> - Are there any implementation of JSONRPC2 on sockets using JSON
> splitting?

Perl module JSON::XS support JSON splitting and I believe some JSONRPC2
clients/servers in perl are using JSON splitting.

Personally, I prefer to use \n to detect end of JSON, but that mean I'm
using custom transport which may not be compatible with 3rd-party
servers/clients (more precisely single line json ended with \n generated
by my client/server is compatible with 3rd-party server/client, but they
may not generate json in single line or not add \n at end and thus my
client/server may not understand their replies).

> - can a JSONRPC2 server implementation insert a newline at the end of

> each reply JSON object? (in a JSON splitting implementation) My
> understanding is that yes?

Yes.

--
WBR, Alex.

[Matt (MPCM)]

The (JSON) Text Sequences doc out of the IETF is likely to help address this in the near future:
http://tools.ietf.org/html/draft-ietf-json-text-sequence-04