Re: RMI in java
Roedy Green wrote:
On Tue, 1 Sep 2009 08:29:05 -0700 (PDT), david <davidzeu@gmail.com>
wrote, quoted or indirectly quoted someone who said :
Should the server 'act' like a client and try to update every client
using an RMI objects exported in the clients' side?
There would have to be a thread at the clients listening for these
probes. It may be simpler to do it the Borland Paradox way.
Have your clients to a quick probe every N seconds to you RMI server
to see if anything has happened recently.
A harder way to do it would be to get the server to send out a UDP
broadcast to each client on a different socket. The client dedicates a
thread just to listening for that incoming packet that means
"something happened -- for details probe the server."
Another pattern is to have clients register with the server as interested in
given events or results. They do this by making a call to the server that is
not returned immediately, but only after something becomes available.
This puts thread pressure on the server but is a simple model to implement.
Clients will usually be multi-threaded also, so that registration with the
server doesn't halt other action.
I learned this model in days of yore with operating systems that used
send-receive-reply semantics for inter-process communication. The receiving
task, the RMI server in our scenario, was called a "resource manager" and was
the gateway for all clients to whatever service it provided. Clients would
send to the resource manager and block on a reply that was contingent on
server-side availability. The resource manager would "send" to interested
clients by replying to their messages.
--
Lew