Can Server send Notifications to client?

[SteelRat]

I have made server on JSON-RPC technology for my project. But I need
to send data to client, to save traffic and time. Client makes a
permanent connection to server, and send notification, that he is
waiting for new actions. After that server send to client
notifications, when actions appear on server.
Whether it is compatible with JSON-RPC 2.0 Specification?

[Vinícius dos Santos Oliveira]

I have this doubt too.
Someone here could answer it?

2011/5/23 SteelRat <steelr...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To post to this group, send email to json...@googlegroups.com.
To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-rpc?hl=en.

--
Vinícius dos Santos Oliveira
https://profiles.google.com/118295250366112843114/about

Linux user #481186

Majoring in Computer Science
Instituto da Computação at Universidade Federal de Alagoas
Maceió, Alagoas, Brazil

"Who cares?" -???

[Skylos]

The answer is No, the server cannot sent unsolicted responses to the client.

There are ways of making this behavior happen that do not exclude the possibility of using JSONRPC 2.0 to solve it, but you'll effectively be building a bidirectional peer communication system as a layer on top of JSONRPC, which doesn't do this all by itself.

Skylos

2011/5/30 Vinícius dos Santos Oliveira <vini.i...@gmail.com>

--
"If only I could get rid of hunger by rubbing my belly" - Diogenes

[Henry Unger]

Why not? If it is implemented over a socket, what’s to prevent either side from sending notifications to the other?

 

Henry

[Yitzchak Scott-Thoennes]

Nothing's to prevent it, but then the "server" is the client and the
"client" is the server.

[Rasjid Wilcox]

There is nothing stopping you from having each end acting as both
client and server (ie, a peer to peer arrangement). In fact, there
are at least two implementations of JsonRpc 2.0 over TCP that do this.
One at https://github.com/niligulmohar/python-symmetric-jsonrpc,
another at http://www.openminddev.net/projects/projects/show/python-rpcbd
- there may well be others.

Cheers,

Rasjid.

[Henry Unger]

In a publish/subscribe scenario, the subscriber is usually referred to as the client, the publisher referred to as the server, and the publisher sends notifications to the subscriber. In my mind, there is no role reversal.

> -----Original Message-----
> From: json...@googlegroups.com [mailto:json...@googlegroups.com] On

> --
> You received this message because you are subscribed to the Google
> Groups "JSON-RPC" group.
> To post to this group, send email to json...@googlegroups.com.
> To unsubscribe from this group, send email to json-

> rpc+uns...@googlegroups.com.

[Vinícius dos Santos Oliveira]

Agreed

2011/5/30 Henry Unger <hun...@hitech.com>

To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/json-rpc?hl=en.

[Iñaki Baz Castillo]

2011/5/31 Henry Unger <hun...@hitech.com>:

> In a publish/subscribe scenario, the subscriber is usually referred to as the client, the publisher referred to as the server, and the publisher sends notifications to the subscriber. In my mind, there is no role reversal.

This thread is mixing "TCP client" with "JsonRPC client". Nothing
mandates that the JsonRPC client should establish a TCP connection
with a TCP server. In fact JsonRPC dones't (or shouldn't) say nothing
about the transport protocol.

For example, JsonRPC could be used between two UDP sockets sending
requests one to each other. And in UDP, there is no concept of
"server" neither "client".

Please don't mix the transport protocol with the application protocol.
See OSI/IP layers.

--
Iñaki Baz Castillo
<i...@aliax.net>

[Rasjid Wilcox]

On 31 May 2011 10:33, Henry Unger <hun...@hitech.com> wrote:
> In a publish/subscribe scenario, the subscriber is usually referred to as the client, the publisher referred to as the server, and the publisher sends notifications to the subscriber. In my mind, there is no role reversal.

All well and good, but in terms of JsonRpc the terms 'client' and
'server' have specific meanings. By definition, the 'client' sends
requests and notifications, and the 'server' replies with responses.
Any other use of the terms 'client' and 'server' within the context of
the spec just creates confusion.

As noted elsewhere, this has *nothing* to do with the transport layer,
and says nothing about which side initiates the connection at a
transport level. When using plain TCP as the transport, it is
certainly possible to have a 'listening client' that waits for
incoming connections from JsonRpc 'servers', and then sends requests
to them. But from the spec perspective, if an end-point sends
requests, it is a 'client', and if it sends responses, then it is a
'server'. A single end-point may well be both.

Cheers,

Rasjid.

[Iñaki Baz Castillo]

2011/5/31 Skylos <sky...@gmail.com>:

> The answer is No, the server cannot sent unsolicted responses to the client.

Fully wrong. A server is what I decide a server is. The application
protocol (JsonRPC in this case) must not make assumption about the
transport layer. Never.

When entity A sends a JsonRPC request to entity B, entity A is acting
as a JsonRPC client and B as JsonRPC server. If entity B sends a
JsonRPC request it behaves as a JsonRPC client and entity A as JsonRPC
server. *NOTHIN* must mandate that they cannot share the same TCP
connection, neiher such TCP connection must exist (what about UDP
transport? UnixSocket? any other protocol on top of
TCP/UDP/UnixSocket?

[Skylos]

When speaking of json-rpc spec, server is the responder and client is the initiator, there isn't any ambiguity.  A json-prc server cannot send unsolicited messages, the concept is incompatible with the protocol.  Thus the answer is No, that is not compatible.

If your endpoint utilizes multiple connections with streams of json-rpc, on some connections using the role of a json-rpc client and other connections using the role of json-rpc server, and those virtual connections are multiplexed across some other transport that no specification we're talking about cares about, then... the question doesn't even get asked, there isn't a compatibility question to answer?

Or maybe I'm just too close to it to see how its not obvious?

Skylos

--

You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To post to this group, send email to json...@googlegroups.com.
To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-rpc?hl=en.

[Iñaki Baz Castillo]

2011/5/31 Skylos <sky...@gmail.com>:

> When speaking of json-rpc spec, server is the responder and client is the
> initiator, there isn't any ambiguity.  A json-prc server cannot send
> unsolicited messages, the concept is incompatible with the protocol.  Thus
> the answer is No, that is not compatible.
> If your endpoint utilizes multiple connections with streams of json-rpc, on
> some connections using the role of a json-rpc client and other connections
> using the role of json-rpc server, and those virtual connections are
> multiplexed across some other transport that no specification we're talking
> about cares about, then... the question doesn't even get asked, there isn't
> a compatibility question to answer?
> Or maybe I'm just too close to it to see how its not obvious?

I clearly spoke about entity A and entity B which communicate using
*some* transport protocol we don't care about (TCP, UDP, UnixSocket)
or maybe using JsonRPC on top of other application protocol (HTTP or
whatever).

I just said that entity A can send JsonRPC requests to B (so it
behaves as a JsonRPC client). But nothing stops entity B behaving as a
JsonRPC client and sending JsonRPC requests/notifications to entity A
(which would become a JsonRPC server for those requests).

It doesn't matther which entity initiated the "connection" (as not all
the transports have "connections").

Regards.