# RMI Tracer



## itstata (10. Jun 2008)

hallo,
erstmal muss ich sagen, dass ich an einem punkt bin, wo ich von rmi wirklich begeistert bin.
ich hatte ne ganze zeit bisschen angst, dass meine applikation nicht hinter routern oder firewalls funktioniert, aber dem ist nicht so.

ich betreibe einen server hinter einem router (ports werden zum server weitergeleitet!) der eine softwarefirewall hat.
der client hat auch ne softwarefirewall wo die entsprechenden ports (1098/9) gesperrt sind. klappt alles prima, rmi wechselt scheinbar automatisch auf port 80. so soll es auch sein.
gibt es aber eine möglichkeit, zu prüfen, ob er wirlich den ensprechenden weg der anfrage geht? ich bin der meinung, dass ich mal sowas im forum hier gesehen habe.

gruß L.


----------



## itstata (10. Jun 2008)

ich teste gerade ein bisschenb mit dem befehl netstat in der konsole rum, rmi nutzt komischerweise die ports 49393 und 49394. laut der seite 
www.cs.swan.ac.uk/~csneal/InternetComputing/Tunnelling.html(Kapitel 9.2 (2)) müsste rmi jetzt eigentlich ein http-request absenden. schade, dass ich das nicht sehen kann.


----------



## tuxedo (10. Jun 2008)

>> ich hatte ne ganze zeit bisschen angst, dass meine applikation nicht hinter routern oder firewalls funktioniert, aber dem ist nicht so. 

Solange du keine Callbacks verwendest (und die sind wirklich ne tolle Sache), wird das bei dir auch so bleiben.

Zur Tunneling-Sache:

RMI wechselt nicht "automatisch" auf Port 80. Wenn ich mich jetzt nicht total irre, brauchst du für das HTTP-Tunneling ein CGI-Script das auf einem Webserver läuft (was auch in deiner verlinkten Doku so steht). 
Was RMI laut deiner verlinkten Doku kann, ist mit dem voreingestellten Port (üblicherweise 1099) HTTP zu sprechen. D.h. die Anfragen werden in einen HTTP-Request verpackt. Aber das bringt dir in Sachen "Client sitzt hinter einem Router" rein gar nix. Auch HTTP-Tunneling bringt da nix. Sofern du also keine Callbacks verwendest: Mach dir keinen Kopf drum wie und wo RMI was überträgt. 

Im übrigen: Das Tool was du suchst, nennt sich "Wireshark". Aber Achtung: Die Verwendung und der Besitz ist dank des "ach so tollen Hackerparagraphen" in Deutschland mindestens umstritten, wenn nicht sogar "illegal". Die verwendung ist nebenbei auch nicht ganz einfach wenn man sich mit den tieferen OSI-Schichten nicht so gut auskennt. 

- Alex


----------



## itstata (11. Jun 2008)

oohh wireshark hab ich sogar schon drauf  bin ich jetzt böse?
ne im ernst, hatte das verwendet um zu testen, ob ssl (bzw. die verschlüsselung) funktioniert.
also ich werd mich jetzt mal schlau machen, was callbacks eigentlich sind. scheinbar nutze ich sie nicht, da es bisher funktioniert. danke für die antwort!


----------



## tuxedo (11. Jun 2008)

Callbacks in Sinne von RMI sind RemoteObjekte, die auf Clientseite erzeugt werden und dem Server über einen Methodenaufruf mitgeteilt werden. Der Server kann dann über diese RemoteObjekte Methoden am Client aufrufen. Diese Aufrufe nennt man Callbacks.

Im Falle von RMI hab ich noch keinen Weg gefunden die Callbacks über die gleiche Socketverbindung zurück zum Client zu routen. RMI baut hierfür von Haus aus eine neue Socketverbindung auf. Sitzt der Client dann hinter einem Router ist "Ende Gelände". Der Port, zu dem sich der Server beim Client zu connecten versucht, ist dummerweise auch nicht immer der gleiche, so dass ein Portforwarding im Router des Clients nix bringt. Ergo: Problem.

Deshalb auch meine SIMON-Implementierung.
Aber vielleicht findest du ja einen Weg das gleiche mit RMI zu realisieren. Wobei, dann hat RMI noch immer das "normale Socketverbindungs"-Problem. SIMON verwendet mittlerweile NIO und sollte sich deshalb besser skalieren lassen.

- Alex


----------

