In unserer Anwendung verwenden wir RMI für die Client-Server-Kommunikation auf sehr unterschiedliche Weise:
Wir möchten sicherstellen, dass unser gesamter RMI-Code nur ein bekanntes spezifisches Inventar von Ports verwendet. Dazu gehören der Registry-Port (normalerweise 1099), der Server-Port und alle Ports, die sich aus den Callbacks ergeben.
Folgendes wissen wir bereits:
Diese Punkte werden auch in diesem Beitrag im Sun-Forum behandelt.
Was wir nicht wissen, ist: Wie stellen wir sicher, dass die Client-Verbindungen zurück zum Server, die sich aus den Callbacks ergeben, nur eine Verbindung zu einem bestimmten Port herstellen und nicht zu einem anonymen Port?
EDIT: Eine längere Antwort hinzugefügt, die meine Ergebnisse zusammenfasst und wie wir das Problem gelöst haben. Hoffentlich hilft dies jedem anderen mit ähnlichen Problemen.
ZWEITER BEARBEITUNG: Es stellt sich heraus, dass in meiner Anwendung scheint eine Race Condition in meiner Erstellung und Modifikation von Socket-Fabriken. Ich wollte dem Benutzer erlauben, meine Standardeinstellungen in einem Beanshell-Skript zu überschreiben. Leider scheint es, dass mein Skript deutlich ausgeführt wird, nachdem der erste Socket von der Factory erstellt wurde. Als Ergebnis bekomme ich eine Mischung von Ports aus den Standardeinstellungen und den Benutzereinstellungen. Es wird mehr Arbeit erforderlich sein, die außerhalb der Reichweite dieser Frage liegt, aber ich dachte, ich würde es als einen Punkt von Interesse für andere aufzeigen, die diese Gewässer irgendwann betreten müssen ....
Sie können dies mit einer benutzerdefinierten RMI Socket Factory tun.
Die Socketfactorys erstellen die Sockets für RMI, die sowohl am Client als auch am Server verwendet werden. Wenn Sie also Ihre eigenen schreiben, haben Sie die volle Kontrolle über die verwendeten Ports. Die Client-Factories werden auf dem Server erstellt, serialisiert und dann an den Client gesendet, was ziemlich ordentlich ist.
Hier ist eine Anleitung bei Sun, die Ihnen erklärt, wie Sie es tun können.
Sie benötigen dafür keine Socket-Factories oder gar mehrere Ports. Wenn Sie die Registrierung von Ihrer Server-JVM aus starten, können Sie den Port 1099 für alles verwenden, und genau das wird standardmäßig geschehen. Wenn Sie die Registrierung nicht wie in einem Client-Callback-Objekt starten, können Sie Port 1099 beim Exportieren bereitstellen.
Der Teil Ihrer Frage über die aus Rückrufen resultierenden Client-Verbindungen zurück zum Server macht keinen Sinn. Sie unterscheiden sich nicht von den ursprünglichen Clientverbindungen zum Server und sie verwenden dieselben Serverports.
Zusammenfassung der langen Antwort unten: Um das Problem zu lösen, das ich hatte (Server- und Callback-Ports an beiden Enden der RMI-Verbindung einschränkend), musste ich zwei Paare von Client- und Server-Socket-Factories erstellen.
Längere Antwort folgt:
Unsere Lösung für das Rückrufproblem bestand im Wesentlichen aus drei Teilen. Der erste war der Objektumbruch, der die Möglichkeit benötigte anzugeben, dass er für eine Client-zu-Server-Verbindung verwendet wurde, anstatt für einen Server-zu-Client-Rückruf verwendet zu werden. Durch die Verwendung einer Erweiterung von UnicastRemoteObject konnten wir die Client- und Server-Socket-Factorys angeben, die wir verwenden wollten. Der beste Ort zum Sperren der Socket-Factories befindet sich jedoch im Konstruktor des Remote-Objekts.
Also gibt das erste Argument den Teil an, auf dem das Objekt Anfragen erwartet, während das zweite und dritte die Socket-Factors spezifizieren, die an jedem Ende der Verbindung verwendet werden, die dieses entfernte Objekt antreibt.
Da wir die von der Verbindung verwendeten Ports einschränken wollten, mussten wir die RMI-Socket-Factorys erweitern und die Ports sperren. Hier sind einige Skizzen unserer Server- und Kundenfabriken:
%Vor%Beachten Sie, dass die oben genannte Server-Socket-Factory sicherstellt, dass nur der von Ihnen zuvor angegebene Port jemals von diesem Werk verwendet wird. Die Client-Socket-Factory muss mit der entsprechenden Socket-Factory gepaart werden (oder Sie werden nie eine Verbindung herstellen).
%Vor%Also ist das einzige, was übrigbleibt, um Ihre Zwei-Wege-Verbindung zu zwingen, auf dem gleichen Satz von Ports zu bleiben, eine Logik, um zu erkennen, dass Sie zur Client-Seite zurückrufen. Stellen Sie in diesem Fall sicher, dass Ihre Factory-Methode für das Remote-Objekt den RemoteObjectWrapper-Konstruktor oben aufruft, wobei der Callback-Parameter auf "true" gesetzt ist.
Ich habe verschiedene Probleme bei der Implementierung einer RMI Server / Client Architektur mit Client Callbacks gehabt. Mein Szenario ist, dass sowohl Server als auch Client hinter Firewall / NAT stehen. Am Ende bekam ich eine voll funktionsfähige Implementierung. Hier sind die wichtigsten Dinge, die ich getan habe:
Öffnen Sie auf dem Computer Firewall / Router / Lokaler Server den Port 6620. Öffnen Sie auf dem Computer Firewall / Router / Lokaler Server den Port 1099. Auf dem Router / NAT umleiten eingehende Verbindungen an Port 6620 zu 192.168.1.10:6620 Auf dem Router / NAT umleiten eingehende Verbindungen auf Port 1099 zu 192.168.1.10:1099
Im aktuellen Programm:
%Vor%Öffnen Sie auf dem PC Firewall / Router / Lokaler Server den Port 1999. Auf dem Router / NAT werden eingehende Verbindungen an Port 1999 zu 10.0.1.123:1999
umgeleitetIm aktuellen Programm:
%Vor%Hoffe, das hilft. Iraklis