Est-il acceptable d'utiliser des objets multiples pour la communication RMI

Question

Scénario:

• client C se connecte au serveur S via RMI
• C demande S pour créer un gestionnaire H, S retourne H à C
• C parle alors à H

maintenant, je pourrais le faire de deux façons:

• M ake le gestionnaire et un Remote soit S retourner le talon à elle, de sorte que C peut parler directement à celui (h.say(String msg);)
• donner le gestionnaire d'ID et revenir à ce que C. C parlera de H par l'intermédiaire de S (s.sayToHandler(int id, String msg);)

Le premier est plus agréable OO, mais qu'en est-il de la performance? Une connexion TCP supplémentaire sera-t-elle ouverte ou la connexion existante entre S et H est-elle utilisée?

Answer 1

Je ne connais pas l'implémentation. Je ne pense pas qu'une nouvelle connexion est faite. Mais ce que je sais, c'est que plus vous partagez d'objets à distance, plus il y a d'objets qui dépendent du déréférencement à distance pour récupérer les ordures (il y aura donc plus d'objets qui vivent plus longtemps).

approche alternative

Je recommande une approche mixte. Utilisez l'approche agréable pour le client, mais la mettre en œuvre le pas si beau sens interne:

interface Server { 

    public Handler getHandler(...); 
} 

interface Handler extends Serializable { 
    // it gets copied! 
    public X doThis(...); 
    public Y doThat(...); 
} 

class HandlerImpl implements Handler { 
    public X doThis(...) { 
    backDoor.doThis(this, ...); 
    } 
    public Y doThat(...) { 
    backDoor.doThat(this, ...); 
    } 

    private BackDoor backDoor; 
} 

interface BackDoor { 
    public X doThis(Handler h, ...); 
    public Y doThat(Handler h, ...); 
} 

class ServerImpl imlpements Server, BackDoor { 
    public Handler getHandler(...) { 
    return /*a handler with a self reference as backdoor, only ONE remote obj shared via TWO interfaces */ 
    } 
    ... 
    // it does everything 
    // it receives the handler 
} 

BackDoor et gestionnaire sont des interfaces sync'ed. Le premier a les méthodes avec Handler comme argument, le dernier a les méthodes pures. Je ne pense pas que ce soit un gros problème. Et les deux interfaces différentes vous permettent de travailler proprement sans que le client ne sache rien et permettent au Handler sériable de faire le sale boulot.

J'espère que vous l'aimez!

Answer 2

La spécification RMI ne dit pas vraiment si une nouvelle connexion doit être établie ou si la connexion existante doit être réutilisée. Le protocole filaire permet à la fois, en utilisant soit multiplexing ou une connexion TCP par appel (qui pourrait être réutilisé pour suivre les appels au même objet sever, je ne suis pas sûr). Si vous avez besoin de tunnelliser via HTTP, un seul message par connexion est autorisé.

Je n'ai trouvé rien sur la façon de configurer le type de protocole à utiliser (autre que la désactivation de la tunnellisation HTTP).

Si vous souhaitez vous assurer qu'une seule connexion TCP est utilisée, utilisez des fabriques personnalisées de sockets client et serveur qui effectuent le tunneling de plusieurs connexions. Ce sera probablement moins efficace que ce que le système d'exécution RMI ferait là.