SIMON

Sieht interessant aus. Ich werd's mir gleich mal näher anschauen.

Einfach so "anpassen"... Weiß nicht ob das geht. Denn RMI nutzt das gute alte "Blocking IO" und wir nutzen hier "Non-Blocking IO". Mit einsetzen einer Socket-Factory ist es wohl nicht getan. Aber vielleicht kann ich das ganze einfach nachbauen.

Meld' mich wieder wenn ich genaueres weiß.

- Alex

So, hab einen ersten Blick rein geworfen... Wo da "hole-punching" stattfinden soll ist mir noch ein Rätsel. Denn RMI basiert auch einer TCP Kommunikation, während "Hole Punching" klassisch auf "UDP", nämlich dem "UDP Hole Punching" basiert. Es gibt zwar auch TCP Hole Punching, aber das geht soweit unter in den TCP Stack dass man da mit "Java Only" wohl nicht hinreichend Möglichkeiten hat.

Deren RMI Hole Punching ist offensichtlich mit GPL Lizensiert. Aber es gibt nirgends einen Hinweis auf den Source. Hab ihn mir mal bis auf weiteres decompiliert. Nirgendwo hab ich die Verwendung von Datagrammen (UDP) entdeckt. Wie die echtes Hole-Punching machen ist mir noch ein Rätsel. Aber ich komm noch dahinter....

- Alex

Okay, ich weiß nun wie's funktioniert. Werde das wohl weitgehend nachbauen müssen. Die bestehende Implementierung einfach an SIMON adaptieren ist wohl aufwendiger, da SIMON intern ein ganz anderes Prinzip verwendet.

Noch ne Frage zur bestehenden Java RMI Lösung: Bist du auf den Mediator-Server der Implementierung angewiesen, oder kommt's dir nur drauf an eine Hole-Punching Technik zu haben, egal welche? Sprich: Müsste die SIMON Lösung mit dem existierenden Mediator funktionieren?!

Weitere Frage: bei RMI macht das Hole-Punching durchaus Sinn. Denn wenn man Callbacks verwendet, dann gibt es Probleme wenn der Client hinter einem NAT sitzt, denn der Server baut hier dann auch eine Verbindung zum Client auf. Bei SIMON ist das anders. Hier gehen alle Netzwerk-Verbindungen vom Client zum Server, und nicht umgekehrt. Was ich jetzt nicht ganz verstehe: Was ist der Use-Case einer Hole-Punching Lösung in Verbindung mit SIMON? Wo spart man sich denn den Aufwand? Statt die Firewall/Router des Server-NATs mit einem PortForwarding zu versehen muss ich einen Mediator-Server auf einem Rechner betreiben der hinter keinem NAT sitzt. Dann könnte ich doch gleich den SIMON-Server auf diesem NAT-losen Server betreiben, oder?
Im klassischen Client/Server betrieb leuchtet wir das Hole-Punching irgendwie noch nicht ein.
Im Peer-to-Peer Betreib schon eher. Aber da wird doch dann ein einfacher Mediator-Server nicht ausreichen, oder?
Nehmen wir mal an wir haben 20 Peer-Rechner und einen Mediator. Wenn jetzt jeder mit jedem kommunizieren können soll, dann wird's schon stressiger. Der Mediator-Server müsste auskunft über alle Peers geben können und und und. Das deckt, soweit ich das gesehen hab, auch die Java RMI Hole-Punching Technik der Uni KOnstanz nicht ab. Hier muss man sich auch gleich überlegen ob TCP überhaupt das richtige Protokoll, und RPC die richtige Technik dafür ist.

Um's auf den Punkt zu bringen:

Was genau hast du vor? ;-)

- Alex

:D Ich hatte gefürchtet, dass es darauf hinausläuft. Dann enthülle ich mal mein Projekt:
Vorweg: Ja, das klingt kindisch und verspielt und überhaupt nicht professionell. Das weiß ich.

Ich programmiere eine Software, die man heimlich auf dem Computer eines Freundes installiert um ihm anschließend über das Internet Streiche zu spielen. Die Software ist bereits so weit gediehen, dass die Installation per Java Web Start nur wenige Sekunden benötigt und vollkommen unbemerkt abläuft. Zu Hause startet man dann den "Observer", mit dem man auf dem PC des Freundes Textnachrichten erscheinen lassen kann, das CD-ROM-Laufwerk öffnen und schließen und YouTube-Videos aus dem Nichts abspielen lassen kann. All das ist bereits implementiert und funktioniert hervorragend dank SIMON.

Bisher verlasse ich mich dabei auf Dynamic DNS. Wenn man die Software in den PC des Freundes einschleust, während dieser auf dem Klo ist oder was auch immer, muss man die DNS-Adresse des eigenen Computers angeben. Die Software versucht dann alle zehn Sekunden sich mit dem "Observer" zu verbinden. Schalte ich zu Hause meinen PC ein, klappt die Verbindung und ich kann mit den Streichen beginnen.

Ich plane jetzt einen "Observer" für Android-Smartphones. Da die Android-Plattform komplett auf Java aufsetzt, kann ich einen großen Teil des Codes übertragen und die Verbindung ohne zusätzliche Abstrahierung direkt mit SIMON aufbauen. Allerdings steht bei UMTS kein Dynamic DNS zur Verfügung und der Verbindungsaufbau zum "Observer" schlägt mangels Port-Weiterleitung fehl. Ich dachte daher, dass eine Hole-Punching-Technologie mit einem Mediator auf einem Webserver Abhilfe schaffen könnte.

Nein, ich bin nicht auf die Mediator-Implementierung der Uni Konstanz angewiesen. Ich hatte vor meinen eigenen HTTP-Mediator zu schreiben, der die Adressen austauscht.

- Petroy

Ach ja, der Quellcode der Implementierung ist verfügbar unter http://ice.in.htwg-konstanz.de/xref/index.html
Decompilieren wäre nicht nötig gewesen.

Ähm, okay... Ich kann niemandem verbieten SIMON so einzusetzen :-) Aber gut heißen will ich dein Vorgehen nicht.

In deinem Fall kannst du dir HolePunching komplett sparen. Denn dein "Spaßtool" muss kein Server sein. Lass es einfach ein Client sein der sich zu DIR, zu DEINEM Server verbindet. Fertig (Stichwort: Nach Hause telefonieren ...).

Zur Android-Sache:

Hab noch nicht geschaut, aber bist du sicher dass auf Android die NIO Packages verfügbar sind? Denn SIMON baut auf MINA auf, welches wiederum auf Java Non-Blocking IO (kurz NIO) aufbaut.

- Alex

Ja, die NIO Packages sind verfügbar.
Ich wollte eigentlich schon, dass das Programm auf dem infizierten PC sich mit dem kontrollierenden PC verbindet, da sonst umfangreiche Firewall-Einstellungen und DynDNS-Einstellungen auf dem infizierten PC erfolgen müssten. Das widerspricht dem Konzept der unbemerkten Fünf-Sekunden-Installation :D

Naja, ich schau mal was ich mache.

- Petroy

Ich wollte eigentlich schon, dass das Programm auf dem infizierten PC sich mit dem kontrollierenden PC verbindet, da sonst umfangreiche Firewall-Einstellungen und DynDNS-Einstellungen auf dem infizierten PC erfolgen müssten. Das widerspricht dem Konzept der unbemerkten Fünf-Sekunden-Installation :D

??? Das ist doch genau das was ich vorgeschlagen hatte ...

Du lässt den SIMON Server bei dir daheim auf nem Rechner laufen, richtest da Portforwarding und alles notwendige ein.

Der Client (also der "infizierte" Rechner) verbindet sich dann mit dieser fest vorgegebenen Adresse. Das hat keinerlei Auswirkungen auf Webstart und Co.

Wenn du dann noch mit den Android-Handy einen solchen Client "steuern" willst, gehst du direkt über deinen Server daheim der dann als "Relay" zum Client dient.

- Alex

P.S. Werd' mir wohl noch ein Android zulegen müssen...

Ach so, sorry, hab ich falsch verstanden. Ja gut, dann muss ich mir einen Home-Server zulegen, der die ganze Zeit läuft. Naja, vorher probier ich lieber die Hole-Punching-Methode, bei der der Server auf dem Smartphone läuft. Ich könnte doch den ganzen SIMON-Datenverkerhr durch eine Art lokalen Proxy leiten der die Verbindung durch Hole-Punching weiterleitet. Mal sehn, ob ich das hinkriege. Jetzt muss ich aber erst mal warten bis mein Android ankommt :)

- Petroy

P.S. Jaaa, Android soll super sein!

Ja gut, dann muss ich mir einen Home-Server zulegen, der die ganze Zeit läuft.

Ähm, da hast du was nicht zuende gedacht. Für das Hole-Punching gemäß Uni Konstanz brauchst du ebenfalls einen 24/7 Server, und das sogar ohne NAT. Von daher bist du mit einem "Homeserver" mit selbst eingerichtetem PortForwarding im DSL-Router besser/billiger dran.

Naja, vorher probier ich lieber die Hole-Punching-Methode, bei der der Server auf dem Smartphone läuft. Ich könnte doch den ganzen SIMON-Datenverkerhr durch eine Art lokalen Proxy leiten der die Verbindung durch Hole-Punching weiterleitet. Mal sehn, ob ich das hinkriege.

Das klingt mehr als verwirrend. Einen Server auf dem Smartphone laufen lassen? Wie willst du das machen? Du hast eine dynamische IP. Dann müsstest du einen DynDNS-Dienst mit dem Handy kombinieren. Aber ob das gut geht?! Zudem: DynDNS dauert unter umständen 1-2h bis der Hostname auf die IP des Handys zeigt. Willst du also mit (im worst case) 1-2h vorlaufzeit den Server auf dem Handy vorstarten, bevor dann der Client irgendwann durch den DNS die richtige IP bekommt?

Mein Tipp:

Lass nen Server daheim laufen zu dem sich der Client hinverbindet. Und dein Smartphone verbindet sich da auch hin und kann dann die CLients steuern/regeln/...

- Alex

achristian wrote:

Ja gut, dann muss ich mir einen Home-Server zulegen, der die ganze Zeit läuft.

Ähm, da hast du was nicht zuende gedacht. Für das Hole-Punching gemäß Uni Konstanz brauchst du ebenfalls einen 24/7 Server, und das sogar ohne NAT. Von daher bist du mit einem "Homeserver" mit selbst eingerichtetem PortForwarding im DSL-Router besser/billiger dran.

Ich dachte da für Hole-Punching an einen HTTP-Webserver von bplaced.net.

Naja, vorher probier ich lieber die Hole-Punching-Methode, bei der der Server auf dem Smartphone läuft. Ich könnte doch den ganzen SIMON-Datenverkerhr durch eine Art lokalen Proxy leiten der die Verbindung durch Hole-Punching weiterleitet. Mal sehn, ob ich das hinkriege.

Das klingt mehr als verwirrend. Einen Server auf dem Smartphone laufen lassen? Wie willst du das machen? Du hast eine dynamische IP. Dann müsstest du einen DynDNS-Dienst mit dem Handy kombinieren. Aber ob das gut geht?! Zudem: DynDNS dauert unter umständen 1-2h bis der Hostname auf die IP des Handys zeigt. Willst du also mit (im worst case) 1-2h vorlaufzeit den Server auf dem Handy vorstarten, bevor dann der Client irgendwann durch den DNS die richtige IP bekommt?

Das DynDNS-Problem nervt mich in der Tat. Deswegen ja Hole-Punching mit Webserver als Mediator. Ich dachte, da könnte ich einen extra Prozess laufen lassen, der Daten an einem Port annimmt und sich um das Hole-Punching kümmert. Er schleust dann den Datenverkehr zum Empfänger durch. Genauso auf der Gegenseite. Und SIMON verbindet sich dann immer mit localhost:port . Das kriegt dann doch gar nix davon mit, dass die eigentliche SIMON-Gegenseite nicht auf dem lokalen System läuft. Oder geht das nicht?

Mein Tipp:

Lass nen Server daheim laufen zu dem sich der Client hinverbindet. Und dein Smartphone verbindet sich da auch hin und kann dann die CLients steuern/regeln/...

Sollte all das nicht funktionieren, werd ich das auch machen :) Bleibt ja sonst nix übrig...

Vielen Dank für die ausführlichen Vorschläge,
Petroy

bplaced.net bietet nur HTTP Dienste an. Da ist nix mit:

einen extra Prozess laufen lassen, der Daten an einem Port annimmt und sich um das Hole-Punching kümmert.

Für sowas brauchst du für gewöhnlich einen (v)Root Server. Und die gibts nicht kostenlos.

- Alex

nein nein nein nein :D:D so mein ich das doch gar nicht.

Der HTTP-Mediator tauscht nur die IP-Adressen und Ports aus. Da meldet sich der Server und der Client an. Und der extra Prozess läuft auf den jeweiligen Computern! Ich meine, damit ich die Hole-Punching-Technologie nicht in deinen SIMON-Code einpfriemeln muss. SIMON-Client verbindet sich mit localhost:beliebigerPort und der Prozess nimmt dann die Daten entgegen, schleust sie per Hole-Punching zum Server und schickt den Rest zurück.

- Petroy

Petroy wrote:

Hallo,
die Uni Konstanz hat für Java RMI ein Hole-Punching-Framework bereitgestellt. Es wirkt nicht sonderlich kompliziert. Kann man es auch so anpassen, dass es mit SIMON funktioniert?

Informationen unter http://ice.in.htwg-konstanz.de/

Gruß,
Petroy

Hallo,

Ich bin auf diese Seite gestoßen, weil ich mich für eine RMI alternative interessiere. Ich bin Student an der Uni Konstanz und muss daher sagen, dass das nicht die Uni, sondern die FH ist was du da hast ;-) . Es gibt auch noch eine Universität in Konstanz.

Mit freundlichen Grüßen,
Daniel