May I send request from Server to Client over WebSocket connection

[Kirill Ratkin]

Hi,

I implement client-server RPC communication (client is not Web browser) and want to use JSON-RPC 2.0 spec over WebSocket.

But what I don't understand from JSON-RPC 2.0 specification is request from server to client (not just notification).

I have client connected to server. Client can call server's methods. Server can send notification. It's clear.

But I want to sent request from server to client (not just notification) because I want to be sure client receives and successfully processed data from server.

Notification from server to client doesn't allow server to make sure about it because client doesn't confirm something, It's clear.  it's just notification.

May I send requests from server to client according with specification?

If yes, are there libraries for Java/C#/Python/JS which support it?

// BR

// Kirll

[Andrew Arnott]

JSON-RPC is a peer to peer protocol. There is no server or client role assigned and therefore all message types may go in either direction.

If you hear people referring to the 'server' or 'client' in a JSON-RPC connection, it's just a useful term to describe the one that is receiving the request at the time. Either party can play "server" if the request is coming to it.

I hope all JSON-RPC libraries embody this peer-to-peer mindset, but I can't say for sure. But here are two libraries that do work with bidirectional requests:

https://www.npmjs.com/package/vscode-jsonrpc 

https://www.nuget.org/packages/streamjsonrpc 

Both of these libraries are authored and actively maintained by Microsoft.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/json-rpc/f31a4806-276d-4bcf-907d-7b53cd943eff%40googlegroups.com.

[David Ellis]

Are you being obtuse? The specification itself uses Client-Server terminology. "A rpc call is represented by sending a Request object to a Server."

It is *possible* for both sides to play both roles, but that requires both to be able to address one another -- either by the actual server having a continuous websocket connection as in Kiril's case, or by all parties being fully addressable which is not the case with browsers potentially behind NATs.

A library does not need to provide peer-to-peer functionality to be considered a JSON-RPC library, and to say anything otherwise is to be misleading at best.

David

To unsubscribe from this group and stop receiving emails from it, send an email to json...@googlegroups.com.

[Andrew Arnott]

Are you being obtuse? 

I don't like to think of myself that way, no.

 

The specification itself uses Client-Server terminology. "A rpc call is represented by sending a Request object to a Server."

That's within the context of a particular request. I mentioned in my last email that in the context of a request, a client and a server are merely playing that role for that particular communication.

The 2.0 spec even suggests peer-to-peer capability:

Most 2.0 implementations should consider trying to handle 1.0 objects, even if not the peer-to-peer and class hinting aspects of 1.0.  

 

I've reviewed many network protocol specs, and there is a very distinct line between p2p and client/server protocols. In client/server protocols, the role of each party is absolutely clear and the protocol is asymmetric based on their distinctive roles. In JSON-RPC, the protocol is naturally peer-to-peer because there are no preassigned roles, and all messages can go either direction. 

But the JSON-RPC spec leaves many aspects completely unaddressed, such as the encoding used, separation between messages, and even the transport, leaving wild variations of so-called JSON-RPC messages in transports that are clearly client-server. For example JSON-RPC over HTTP is clearly a one-message, client-server protocol because HTTP is client-server. But that client-server nature isn't from JSON-RPC itself, which is fundamentally a p2p protocol.

Anyway, I won't quibble any more on the subject. I freely admit that the json-rpc spec isn't as precise as I'd like it to be, which leaves interpretation open. I don't feel compelled to convince anyone of my interpretation. 

But as the original question was interested in p2p scenarios, I will emphatically state that JSON-RPC does work great in P2P configurations, and that's all I use it for. The original question also asked for implementations that supported P2P, which I also provided.

So let's please not criticize the community for responding with an answer that helped the original asker. :)

If perhaps you're offended because you felt my answer undercut implementations that expose only a client or only a server role, well, I'm sorry you felt offended. But yes, I do have a lesser opinion of implementations that only expose a part of what JSON-RPC can do, unless of course they offer the protocol over a transport that is fundamentally client-server as I mentioned.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

To unsubscribe from this group and stop receiving emails from it, send an email to json-rpc+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/json-rpc/ff7c2841-3a75-48b3-a74a-39c880fda8d4%40googlegroups.com.