multiple responses or notification from server to clients

368 views
Skip to first unread message

Gandalf Corvotempesta

unread,
May 17, 2022, 4:08:15 PM5/17/22
to JSON-RPC
hi guys

which is the best way to trigger a VERY LONG task on the server and making the client listen to any status updates ? 

Actually, i'm sending a json-rpc request to server, the server starts the task and immediatly reply back to the client with something like "result": "success", then, every 30 seconds, the server send another message to the client, with the origin id, with the progress update.

Is this OK ? (technically, works.)
i can also remove the ID and act as notification , if this would be compatible with specs.

Any other solution ?

Andrew Arnott

unread,
May 20, 2022, 8:43:14 AM5/20/22
to json...@googlegroups.com
Sending two results with the same request id would be a violation of the spec, IMO. My library would reject it and terminate the connection.
Notifications from the server are of course fair game.

The way I did this in StreamJsonRpc is that the result doesn't come until the server is totally done. But during processing, the server sends back notifications. The client is able to correlate the progress notifications to the original request because the original request and the notifications share a 'token' in common. The client creates it, and the server parrots it back with each progress update.

For .NET and Typescript, this allows for a very natural API on the client and server like this:

Task DoSomethingLongAsync(string some, int args, IProgress<T> progressUpdates, CancellationToken)

The JSON-RPC library's job is to translate IProgress<T> objects into a JSON token as it transmits the request. Then while the request is outstanding, the library holds onto the IProgress<T> object so that any notifications from the server carrying that token get relayed back to IProgress<T>.Report(T updateInfo).

I hope that's helpful.

--
Andrew Arnott
"I may not agree with what you have to say, but I'll defend to the death your right to respectfully say it. And I hope you will return the courtesy when the time comes." - my own twist on S. G. Tallentyre


From: json...@googlegroups.com <json...@googlegroups.com> on behalf of Gandalf Corvotempesta <gandalf.co...@gmail.com>
Sent: Tuesday, May 17, 2022 1:46 PM
To: JSON-RPC <json...@googlegroups.com>
Subject: [json-rpc] multiple responses or notification from server to clients
 
--
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/1ce7fca0-e8df-481c-8333-83b59dbd1bf3n%40googlegroups.com.

Gandalf Corvotempesta

unread,
May 26, 2022, 3:50:14 AM5/26/22
to JSON-RPC
Sound good,
so, this is what I did, removing multiple responses but using multiple notification and just a final response:

--> DATA FROM CLIENT TO SERVER
<-- DATA FROM SERVER TO CLIENT


--> {"jsonrpc":"2.0","method":"long.running.task","params":{"progress":{"interval":5}},"id":"8c918fc4-d0e6-472b-bfbe-ce8024c6f91b"}

<-- {"jsonrpc":"2.0","method":"long.running.task/progress","params":{"request_id":"8c918fc4-d0e6-472b-bfbe-ce8024c6f91b","foo": "bar","progress":{"elapsed":2,"remaining":98,"status":"running"}}}
<-- {"jsonrpc":"2.0","method":"long.running.task/progress","params":{"request_id":"8c918fc4-d0e6-472b-bfbe-ce8024c6f91b","foo": "bar","progress":{"elapsed":3,"remaining":97,"status":"running"}}}
<-- {"jsonrpc":"2.0","method":"long.running.task/progress","params":{"request_id":"8c918fc4-d0e6-472b-bfbe-ce8024c6f91b","foo": "bar","progress":{"elapsed":4,"remaining":96,"status":"running"}}}
<-- {"jsonrpc":"2.0","method":"long.running.task/progress","params":{"request_id":"8c918fc4-d0e6-472b-bfbe-ce8024c6f91b","foo": "bar","progress":{"elapsed":5,"remaining":95,"status":"running"}}}
<-- {"jsonrpc":"2.0","method":"long.running.task/progress","params":{"request_id":"8c918fc4-d0e6-472b-bfbe-ce8024c6f91b","foo": "bar","progress":{"elapsed":6,"remaining":94,"status":"running"}}}
<-- {"jsonrpc":"2.0","method":"long.running.task/progress","params":{"request_id":"8c918fc4-d0e6-472b-bfbe-ce8024c6f91b","foo": "bar","progress":{"elapsed":7,"remaining":93,"status":"running"}}}

<-- {"jsonrpc":"2.0","result":{"foo": "bar"},"id":"8c918fc4-d0e6-472b-bfbe-ce8024c6f91b"}

Andrew Arnott

unread,
May 28, 2022, 11:42:53 PM5/28/22
to json...@googlegroups.com
Right: the server can send notifications to the client whenever it wants. In fact JSON-RPC is fundamentally a peer-to-peer protocol. There is no concept of client or server unless you apply that concept in your application. 

I don't use the request id as the progress notification token for two reasons:
  1. The client may want progress reports on more than one thing in the request. But if the request ID is used as the notification token, the server cannot send a notification that is unique to one progress request vs. the other. Consider this example: DoSomethingLong(settings, bytesProgress, percentProgress).
    That may be a poor example, but in real applications, it may be interesting to support this.
  2. The id on the request is an implementation detail of JSON-RPC itself, and therefore isn't always exposed to the application layer. For example StreamJsonRpc simply invokes the server method with the arguments provided by the client, and the server method has no idea what the request id was. If the protocol for progress updates requires knowledge of the request id, that forces it to be implemented by the json-rpc library itself, making it impossible to support at the application layer for those apps using a library that doesn't support progress notifications natively.
--
Andrew Arnott
"I may not agree with what you have to say, but I'll defend to the death your right to respectfully say it. And I hope you will return the courtesy when the time comes." - my own twist on S. G. Tallentyre


From: json...@googlegroups.com <json...@googlegroups.com> on behalf of Gandalf Corvotempesta <gandalf.co...@gmail.com>
Sent: Thursday, May 26, 2022 1:50 AM
To: JSON-RPC <json...@googlegroups.com>
Subject: Re: [json-rpc] multiple responses or notification from server to clients
 
Reply all
Reply to author
Forward
0 new messages