 |
From: Shane Green <sh...@umbrellacode.com>
Date: Sun, 28 Oct 2012 20:38:54 -0700
Local: Sun, Oct 28 2012 11:38 pm
Subject: Re: [json-rpc] JSON-RPC error recovery
That depends on the details. Assuming HTTP/S medium… A JSON-RPC Service accepts JSON-RPC requests and returns JSON-RPC responses. The term "service" should be thought of as a role, more than anything else: the service/server role accepts requests, and returns responses; it does not initiate requests and receive responses. It may happen that the same application is also playing the role of a JSON-RPC client, in which case it is initiating requests sent to a JSON-RPC service, and receiving that service's responses. That service may or may not the same end point that is also a client. If it is the same end point, then you have bidirectional JSON-RPC because both applications are operating in both roles in relation to one another: A is the server for client B, and B is a server for client A. If you were to pipe this bidirectional behaviour through a single connection then you would have an odd setup, as you'd have requests being initiated in each direction over the same pipe. This would not be impossible, or even all that challenging, but it probably wouldn't be a huge benefit unless you were attempting to run two way communication through a network that only allowed one of your two end point to b an actual server and receive incoming connections on port 80, for example. Then you might have the client connect to port 80, then hijack the channel for the server–acting as a client–to initiate requests to the client (acting as a server). You would have to have serious control over the web-server to do this, though. Shane Green On Oct 28, 2012, at 7:53 PM, Henry Unger <hung...@gmail.com> wrote:
> Best regards,
> Henry
> On Oct 11, 2012, at 7:03 PM, "Matt (MPCM)" <mmor...@mpcm.com> wrote:
>> On Wednesday, October 10, 2012 11:23:45 AM UTC-4, David Lee wrote:
>> This is quite simple and straigt forward, and works well. >> This would be problematic because my server needs to send asynchronous notifications back to the client. That requires a persistent connection for the server to have a channel to send the notification back on.
>> A json-rpc server cannot send notifications... that is something reserved for the client. If your running a pair of client/servers on each end of the transport, this can be done of course. >> It occurs to me, though, that this is something else that isn't in the spec. It's allowed, but not required.
>> A client is always a producer of request objects and a consumer of response objects.
>> Can anyone speak as to whether most JSON-RPC implementations can fill both client and server roles, at the same time, to the same client?
>> Some fill both, but generally not at the same time and not over the same transport connection. I don't think most people use the bidirectional nature that the specification allows. There will be people on this list who use it in this way, but for the tech world in general I would say that is not how it is widely used this way.
>> I've played around with bidirectional notification only systems, sort of like udp peering... but in general people reason about their challenge at hand and use json-rpc in an implied sequential style... this has been my observation thus far.
>> regards, >> Thanks!
>> --
>> -- > -- You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||