Hi. If I was creating a client-server application using RMI, I have a couple of questions. My main issue deals with how a server sends responses back to client requests. First, let's start with client to server messages though. My assumption is that the client would lookup the server via RMI and put a message on its queue to be processed (or something like that). However, when a server sends a message, it may need to send it to all clients (maybe a message that the server will be shutting down). What do you think would be the best approach for this?
When a client first connects to the server, the server can keep a reference to that client (by ID number maybe). But then, how does it know how to send the message back to the client? It can't simply lookup the client object via RMI and give the message that way (otherwise it would need to know how to access all the clients).
Maybe the client would poll the server for messages?
Any thoughts on this?
author and iconoclast
The client can have its own remote interface and implement its own servant object, and pass a reference to the server via a "registerCallback()" sort of method. Then when the server needs to tell the client something, it can use that callback. The client servant doesn't need to be registered in any name service, since the server never needs to look it up. It's a quite common design.
The only problem is that this won't necessarily work if the client is behind a firewall; the client would need to set up a SOCKS proxy for that, making it impractical for Internet deployment.