Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Central remote server strategy
Thanks Scott. So there is no way to "ping" a consumer of a remote service through this same service? 

If the service is consumed, the only thing we can do is sent out a new event or remote registration that prompts the client from reading the state again from this object or let the user poll the service.


On Tue, Oct 15, 2013 at 7:18 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Wim,

First...as Markus already commented...the topology of the existing ChatClient might be considered a feature (i.e. no 'server').  Since I haven't really been paying close attention to the intended use cases for the ChatClient, I'm not really sure whether the existing topology is a good idea or not.

More generally though...in a 'group' computing model (i.e. >= 2 group 'members'), there's a long-standing problem called 'distributed consensus'.   Distributed consensus [1] is basically the ability of all parties in a group to agree on the value of some data.    As simple as this sounds, it's not simple in general...as with some topologies (e.g. a network of links between group members), it can be very difficult to define a protocol that guarantees that all group members reach consensus about something as simple as what the current group membership is (i.e. who's 'there' or 'present' in the group).

Of course...a very common approach to dealing with distributed consensus is to have a 'hub and spoke' topology...i.e. where a single process (server) is responsible for group meta-data synchonization...like group membership.    Other approaches are to have/use a consensus protocol...built on top of some topology (e.g. using multicast ip).  There's a description of some of these consensus protocols on [1].

Why do I say all this?  Well...without knowing the ChatClient code I'm not sure this is the case, but it sounds from your statement:

'The idea is to only let the server know about all the clients. The clients communicate with each other through the server. '

...that what you might be trying to get at is a 'group' model...where there are n clients (which are all 'aware' of each other...and able to communicate with other clients), and a server which 'knows' about all clients (group membership)...and serves as a message forwarder.

This seems closer to a what's called a 'topic' in JMS...and lots of other systems...i.e. a 'named group'...aka dynamically changing set of processes.   As Cristiano points out, it also maps reasonably closely to OSGi's EventAdmin.postEvent service...and ECF's distributed event admin implementation can/could be used to implement such a model in a distributed group [2].   Not to mention ECF's datashare API (which provides named channels/topics) and/or others.

As you are probably aware though...the current EventAdmin service API doesn't deal with all the distributed systems issues in a group/topic model...e.g. the API doesn't have any notion of group reliability/membership/failure detection...and in distributed topics/groups, reliable delivery of Events to event handlers is of course not/cannot be guaranteed.  There are also questions of delivery ordering in distributed groups.   There is an OSGi RFP that is beginning to discuss adding to/modifying the EventAdmin service specification to account for distributed systems issues (e.g. reliability and asynchronous messaging)...see [3].

In any event (so to speak :), I think you will find that to do a 'group/topic' model on top of a OSGi Remote Service implementation...where there is no explicit notion of a 'topic'...a 'group'...or 'group membership'...that some of these concepts will/would have to be introduced built on top of some OSGi Remote Service...EventAdmin/DistributedEventAdmin [2]...and/or something of your own creation.  

Scott

[1] http://en.wikipedia.org/wiki/Consensus_(computer_science)
[2] http://wiki.eclipse.org/EIG:Distributed_EventAdmin_Service
[3] RFP 158:  Distributed Eventing https://github.com/osgi/design/blob/master/rfps/rfp-0158-DistributedEventing.pdf




On 10/15/2013 3:05 AM, Wim Jongman wrote:
Hi,

How could I solve a central server configuration with Remote Services? 

The idea is to only let the server know about all the clients. The clients communicate with each other through the server. 

I started with letting the clients consume the server service. But once this service is consumed, how can the server use it to notify the clients of new updates? 

I was naive enough to try a listener model but this does not work does it? If I consume a service and attach a local listener that would not work would it?

How can the consumer be notified of a changed stated in the server service? 

Cheers,

Wim


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


Back to the top