| Re: [ecf-dev] Central remote server strategy |
|
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:
|