• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Liutauras Vilda
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Scott Selikoff
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
  • Frits Walraven
Bartenders:
  • Stephan van Hulst
  • Carey Brown

RMI Client-Server Applications

 
Ranch Hand
Posts: 230
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Nothing? Or something? Like this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic