# Verbindung zu einem Hostrechner über das Internet herstellen



## Chry007 (13. Dez 2011)

Hi,
ich habe eine Frage:
Ich möchte über das Internet eine Verbindung zu einem Rechner herstellen, auf dem ein Hostprogramm läuft. Dieses soll nicht mehr tun als eine Methode aufrufen, die einen übergebenen String lokal in einer Textdatei speichert. Ich erwarte von euch natürlich jetzt kein fertiges Skript, aber es wäre sehr nett, wenn mir jemand einen Hinweis geben könnte, in welcher Richtung ich mich da einlesen muss..

Vielen Dank schonmal im Voraus für eure Hilfe!

Gruß,
Chry


----------



## irgendjemand (13. Dez 2011)

ganz normale socket-verbindung ... nur eben als "ziel" die adresse des routers und dann weiterleiten ...
verstehe problem nicht ... oder hast du generell probleme beim thema socket und network-i/o ?

vielleicht wäre auch sowas in der richtung : port-forwarding , DMZ , udp hole punching , STUN ... und sowas nicht verkehrt ...


----------



## Chry007 (13. Dez 2011)

Das Gebiet ist für mich absolutes Neuland. Socket Verbindung habe ich gerade auch schon was drüber gelesen, werde ich mir anschauen. Wie kann ich denn einen bestimmten Rechner adressieren, der mit dem Router verbunden ist? RouterIP ist klar, und dann weiter? Sorry für die dämliche Fragestellung, wäre auch schon über einen Link dankbar, wo ich mich in die Materie einlesen kann..

Gruß


----------



## tuxedo (13. Dez 2011)

Einen bestimmten Rechner HINTER einem Router adressieren ist nur indirekt möglich. Das Zauberwort (zumindest bei IPv4) heisst: Portforwarding: Du musst im Router einstellen, dass Port XY an den internen Rechner ABC weitergeleitet wird. Alle Zugriffe auf die öffenltiche IP und Port XY werden dann vom Router nach intern zum Rechner ABC weitergereicht. 

Wikipedia und google sollten da weiter helfen können.


----------



## Chry007 (13. Dez 2011)

Es universell so einzurichten, dass der Rechner immer zu finden ist, egal an welchem Router er angemeldet ist, ist nicht zu machen? Beispielsweise, dass der Host die Router IP und einen bestimmten Port im Internet publiziert, der client auf diese Daten zugreift und sie verwendet? 
Mit einem UMTS-Stick hätte ich dieses Problem nicht, oder? 
Gruß


----------



## tuxedo (13. Dez 2011)

Mit einem UMTS Stick solltest du diese "Probleme" nicht haben, da du hier ohne Umweg direkt am Internet hängst.

Sobald ein Router dazwischen ist, trennt dieser mittels NAT das interne (LAN) von externen (WAN bzw. Internet) Netz.
Und dann bringt es auch nix IP und/oder Port des Rechners im LAN irgendwo im Internet zu publizieren: Direktzugriffe auf diesen Rechner enden immer am Router (sofern nicht Portforwarding eingerichtet ist).

Es gibt mittel und Wege dieses Problem zu minimieren:

* UDP Hole Punching
--> Da solltest du mal googeln. Allerdings bist du dann erstmal auf UDP festgelegt und brauchst einen separaten Server im Internet (root/vRoot) der ohne DSL-Router angeschlossen ist. Vorteil: Nach dem Verbindungsaufbau kommuniziert der Client direkt mit dem Server
Nachteil: Klappt nicht immer und überall

* Relais-Server
--> Hier kannst du bei TCP bleiben (oder auch UDP .. ist egal). Allerdings läuft der ganze Traffik zwischen Client und Server über den Relais-Server. Der Trick dabei: Der Client verbindet sich nicht direkt zum Server (denn da würde er ohne Portforwarding am Router enden), sondern mit einem Vermittlingsserver. Der eigentliche Server wartet nicht auf eingehende Verbindungen, sondern verbindet sich ebenfalls zum Vermittluingsserver. Somit hat man zwei AUSGEHENDE Verbindungen (Server->Vermittlungsserver, Client->Vermittlingsserver) und hat die Router-Hürde erstmal überwunden. Allerdings musst du dann am Vermittlungsserver die Datenströme miteinander verbinden. Nachteil: Der ganze Traffik geht über den Vermittlungsserver --> Flaschenhals!!!
Vorteil: Klappt eigentlich immer.

* UPnP
--> Falls der Router UPnP unterstützt und aktiviert hat, kann eine Anwendung auf einem Rechner hinter dem Router den Router für diese Anwendung für Portforwarding einstellen. Automatisch.
Nachteil: NIcht jeder Router kann UPnP (Die meisten Speedport-Teile der Telekom können's nicht, viele Fritzboxen hingegen könnens). Und die die's können, haben UPnP in der Regel per Werksvoreinstellung deaktiviert, so dass man das erst aktivieren müsste. Aber dann kann man auch gleich Portforwarding einrichten... Ergo: In der Regel unbrauchbar ...

Fazit: Server hinter einem Router bedürfen, wenns sauber und zuverlässig laufen soll, direkten zurgiff von aussen. Und bei IPv4 heisst das Mittel der Wahl Portforwarding. 
Mit IPv6 wird's etwas einfacher, aber auch hier wird eine Firewall-Regel nötig sein.

Gruß
Alex


----------



## Chry007 (13. Dez 2011)

Vielen Dank für deine Mühe! Ich hatte darüber nachgedacht, per FTP eine txt Datei auf einem Server anzulegen, auf die der Client schreibt aus der der Server (hinter dem Router) ließt. Das Problem ist, ich brauche eine möglichst schnelle Reaktionszeit und ich befürchte, dass hier der Delay relativ groß sein wird. Wenn ich dich richtig verstehe, hätte ich bei einem Relaisserver das gleiche Problem? 

Danke 

Gruß


----------



## tuxedo (13. Dez 2011)

Nein, im Falle des Relais-Server hast du, wenn du's richtig implementierst kein Delay-Problem:

Am Relais-Server gibt's dann zwei Verbindungen: Eine aus Richtung eigentlichem Server und eine aus Richtung Client. 

Die Implementierung muss dann nur Daten aus der einen Verbindung entgegen nehmen und direkt in die andere Verbindung reinstecken. Du musst also nur die Streams der beiden Socketverbindungen miteinander verbinden (-->Thread). Fertig. Das Delay ergibt sich durch: Laufzeit Client->Relaisserver + Laufzeit Relaisserver->Server
Liegt im normalfall im Millisekundenbereich. Sind Client und Server gut angebunden (sagen wir mal DSL16.000), dann solltest du deutlich unter 100ms Delay liegen (Bsp. Ich hab von meinem DSL16k-Anschluss zuhause eine Laufzeit von 16ms zu meinem Root-Server, vom Büro aus zu meinem Root-Server sind's 13ms. Macht zusammen 29ms Laufzeit vom Büro über den Rootserver zu meinem Heim-Server ...  Ist also durchaus "brauchbar".


----------



## Chry007 (13. Dez 2011)

Hervorragend  Dann werd ich mich da mal einlesen! Hast mir sehr geholfen


----------



## tuxedo (13. Dez 2011)

Persönlich finde ich die Relaisserver Variante nicht so toll.Für richtige Serveranwendungen sollte man Portforwarding bevorzugen. Für Ausnahmefälle und dergleichen ist die Relaisserver-Variante aber hier und da vertretbar...Und denk dran: Relaisserver == Performance-Flaschenhals


----------



## irgendjemand (13. Dez 2011)

@TO
schlag dir die idee mit dem FTP bitte ganz schnell wieder aus dem kopf ...
wir hatten vor nicht all zu langer zeit einen user welcher sich nicht belehren lassen hat das diese technik sehr viele sicherheitsrisiken hat und daher nur in einem vollständig isoliertem v-lan genutzt werden sollte ...

zu deiner ersten antwort auf meinen post : ich hab dir alle nötigen techniken gepostet ... google verwendest du dann bitte selber ...

auch kommt es darauf an was du eigentlich genau umsetzen willst ...
da du von irgendwelchen delay-problemen und schnellem daten-transfer redest soll das ganze wohl "ein spiel" werden *bewusst in anführungszeichen gesetzt* ...
da würde sich UDP Hole Punching eignen da du hier den geringsten delay hättest ...
ein hauptgrund hier UDP zu verwenden : geringster delay

udp ist ein verbindungsloses protokoll ... heißt also : es ist beiden seiten egal ob die daten ankommen ... und in welcher reihenfolge ... natürlich muss der empfänger der diese daten dann verarbeitet auch entsprechend implementiert sein ...

tcp hat hier den nachteil das zu jedem paket was gesendet wurde auch eine bestätigung folgen muss ala "paket angekommen" ..
auch wacht TCP über die reihenfolge der pakete was zu weiterem delay führen kann wenn bereits neuere daten vorhanden sind aber auf grund der reihenfolge noch auf ältere daten gewartet werden muss ...

allerdings hat UHP den nachteil das du irgendwo einen server brauchst der den verbindungsaufbau regelt ...
das ganz heißt dann "STUN" *auch hier helfen google und wikipedia weiter*

zum problem ip :
da *leider ...* ein großteil DSL verwendet um ins netz zu gehen hat man das problem als hoster das sich die public-ip alle 24h ändert *festgeschrieben in irgend ner ur-alt RFC welche die dauer eine telefon-verbindung auf 24h begrenzt* ... muss man dagegen was tun ...
hier heißt das zauberwort : Dynamic DNS ..
heißt also : du verbindest dich nicht zu einer IP sondern zu einem DNS-namen ... der dann in die aktuelle IP aufgelöst wird ...

natürlich erübrigt sich dieses problem mit einer standleitung wie sie bei cable-anbietern die regel ist *ich hab jetzt seit 10 jahren cable-netz und erst die 6te ip oder so ...*

aber noch ein rat : bevor du das ganze übers netz versuchst und dabei verschiedene möglichkeiten probierst versuche das ganze erstmal im LAN hinzubekommen ... wenn das dann läuft kann man sich um das problem NAT kümmern ...

noch als anmerkung : wenn das ganze nicht zeit-relevant ist könntest du auch einfaches port-forwarding verwenden *grad für TCP wichtig* ... man kann zwar auch UDP forwarden ... aber dabei ist nicht garantiert das der ziel-host im LAN auch die richtige remote-IP bekommt ... meistens bekommt er nur die IP des NAT ... wogegen UDP Hole Punching hilft da hier beide seiten vom STUN-server die adressen des anderen dierekt mitgeteilt bekommen und nich auf daten des NAT angewiesen sind


das ganze thema ist sehr komplex ...
vielleicht sagst du uns was du eigentlich vorhast ... dann könnte man vielleicht die eine oder andere variante empfehlen *alles hat vor- und nach-teile .... aber wenn man weis was zu machen ist kann man diese auch richtig abwägen*


----------



## Chry007 (13. Dez 2011)

Ja klar:
Es geht um einen Roboter, der über ein Applet gesteuert wird. Der Roboter schleppt ein Laptop mit sich herum, dass eine Wlanverbindung zum Router aufbaut und die Befehle entgegennimmt. Im Grunde genomen reichen vier Befehle aus: Rechter und linker Motor vor und Rücklauf. Direkt vom Laptop läuft alles, aber jetzt soll das ganze um eine Webcam und Internetverbindung erweitert werden. Und da wäre ein zu großer Delay fehl am Platz. Wobei ich mit zu groß auch keinen Millisekundenbereich sondern eher alles > 1s meine.

Nachtrag:
Zum Thema Sicherheitsrisiko: Im Grunde genommen ist die Sicherheit zweitrangig, da ich das Applet wahrscheinlich eh öffentlich ins Netz setellen werde...


----------



## irgendjemand (14. Dez 2011)

klingt echt interessant ... und sollte mit java definitiv umsetzbar sein

zu klären wären aber noch ein paar dinge

1) steuerungs-software
da du ja sagtest das das ganze übern den *ich nenne es mal entsprechend kombiniert* schlepp-top geht hat dieser also eine software die das ganze steuern kann ...
jetzt ist zu klären : kann man diese software auch von "außen" ansprechen ... also von einem anderen programm ...
dabei sollte man "hacks" vermeiden in dem man z.B. mit Robot tastatur- und maus-eingaben faked ...
besser wäre wenn die software bereits eine network-i/o anbietet ... alternativ wäre auch eine name-pipe nutzbar an die man sich mit java verbindet und dann über java eine network-i/o bereitstellt ...
aber wie gesagt : das hängt von der software ab ... bräuchte man vielleicht etwas infos ...


2) real-time steuerung
da ganze ja ziemlich zeitnah passieren muss braucht man also eine verbindung die sowohl schnelles routing bietet als auch das eintreffen der pakete sicherstellt ...
TCP wäre hier IMHO die "notlösung" mit der man das ganze überhaupt erstmal zum laufen bekommen würde ...
besser wäre etwas was auf UDP basiert ... das problem bei UDP jedoch ist das nicht garantiert wird das die pakete auch ankommen ...
also müsste man auf basis von UDP einen eigenen stack aufsetzen der ab dem verbindungs-aufbau z.b. alle 100ms ein paket erwartet ... wobei egal ist welchen inhalt dieses hat ... dann könnte man da noch eine gewisse latenz-toleranz draufrechnen so das man sagen könnte : wenn länger als 150ms überhaupt KEIN paket eintrifft die aktuelle bewegung stoppen und stehen bleiben *zur sicherheit bevor man sich die stoßstange kaputt fährt oder n regal "umlagert" ... alles schon vorgekommen* ...
natürlich würde das heißen das der aktuelle controller z.B. konstant pakete mit dem command : "beide ketten vorwärts" schicken damit sich der roboter kontinuierlich weiterbewegt ... aber das sollte *mit entsprechenden abständen* zu keinen problemen führen ...
um die netzwerke nicht zu belasten könnte man ein solches paket alle 50ms schicken so das wenn mal EIN paket wegfällt immer noch genug zeit *von den 150ms timeout dann immer noch 100ms bei einem verlorenen paket* bleibt damit das nächste gesendet werden kann ohne das der roboter stehen bleibt ...

darüber müsste man sich aber dann noch mal speziell gedanken machen


3) webcam-stream
da habe ich ganz erlich gesagt relativ wenig erfahrung ... jedoch sollte das in jedem fall mit UDP als stream-cast realisiert werden ... denn beim webcam bild ist es ja egal ob es zwischen durch mal "flackert" weil z.b. pakete verloren gegangen oder in der falschen reihenfolge angekommen sind *hier sollte man protkollseitig einen counter mitlaufen lassen ...* ... auch kann hier die latenz größer sein als bei den steuerungs-commandos was alleine desswegen passieren wird weil es viel mehr daten sind als so ein simpler befehl
wie genau das allerdings geht und ob das mit der verbauten webcam und dem verwendeten treiber mit java umsetzbar ist ... oder ob man dafür spezielle dinge braucht ... das musst du leider google fragen da ich auf dem gebiet keine ahnung habe ...
auch sollte man viel zum thema streaming hier im board oder via google finden ...
*wirklich sorry ... ich kenne mich auf dem gebiet fast null aus*


4) synchronsierung
vielleicht hab ichs nicht ganz verstanden ... aber sollte ich deinem post entnehmen das mehrere user gleichzeitig darauf zugreifen können ? mag ja für die webcam-bilder kein problem sein ... aber für die steuerung ? ... da sollte man natürlich auf eine aktive verbindung gleichzeitig limitieren ... ggf auch authorisierung damit nicht jeder wildfremde damit durch die gegen kurven kann sondern nur die die es auch dürfen ...


allgemein klingt das projekt sehr interessant und sollte sich wie oben erwähnt ohne weitere größere probleme mit java umsetzen lassen ...
versucht das ganze erstmal innerhalb des LAN an das der schlepp-top via wifi angekoppelt ist ... und dann kann man sich was überlegen um das NAT des routers und weitere dinge zu schaffen ...


----------



## TKausL (14. Dez 2011)

tuxedo hat gesagt.:


> Mit einem UMTS Stick solltest du diese "Probleme" nicht haben, da du hier ohne Umweg direkt am Internet hängst.



Dazu muss ich jetzt auch mal meinen Senf abgeben 

Bei UMTS teilen sich mehrere Nutzer eine IP, daher bezweifle ich, dass es bei UMTS so ohne weiteres geht.


----------



## tuxedo (14. Dez 2011)

TKausL hat gesagt.:


> Dazu muss ich jetzt auch mal meinen Senf abgeben
> 
> Bei UMTS teilen sich mehrere Nutzer eine IP, daher bezweifle ich, dass es bei UMTS so ohne weiteres geht.



Oha. Das wusste ist nicht. Hast du da irgendwelche Details/Links dazu?
[update] 
hat sich erledigt. Google war schneller ;-) Trotzdem danke für den Hinweis.


----------



## TheDarkRose (14. Dez 2011)

tuxedo hat gesagt.:


> Oha. Das wusste ist nicht. Hast du da irgendwelche Details/Links dazu?
> [update]
> hat sich erledigt. Google war schneller ;-) Trotzdem danke für den Hinweis.



Meistens so, das bei mobilen Internet der Provider nochmals NAT betreibt.


----------

