Dazu muss ich erstmal mit einem großen Irrtum aufräumen!
ES GIBT KEIN P2P MEHR BEI FSINN!!
Jedenfalls nicht mehr in dem Sinne, wie es einmal war, und ganz speziell, wenn man sich hinter einem Router versteckt (was heute sinnvollerweise die meisten tun) ist das nicht mehr ohne Weiteres möglich.
Hintergrund:
Beim P2P-Verfahren des FSInn muss die exakte IP-Adresse jedes Clients genau aufgelöst werden. Nun gibt es dabei ein Problem, wenn der Client hinter einem Router sitzt. Der FSD-Server befindet sich in einem Netzwerk (dem Internet - WAN)). Bei Dir stellt der Router die Verbindung zum Internet her. Er stellt SICH ins Internet und regelt den Datenverkehr. Dazu ist er mit einer bestimmten IP, die von Deinem Provider vorgegeben wird, an das Internet angebunden. Aber das eigentliche Internet ist auch bei ihm zuende. Heißt: Bis zu ihm gilt die WAN-IP. Dahinter (im LAN)wird mit einem ganz anderen Adressraum (192.168.x.y) gearbeitet. Hier übernimmt der Router die Verteilung der Daten auf die verschiedenen Rechner, die dort jeweils eine IP aus dem LAN-Adressraum haben.
Die Adresse aber, mit dem das Netzwerk arbeitet, mit dem Du Dich verbinden möchtest, existiert nur an Deinem Router, nicht aber an Deinem Rechner. Und schon haben wir das Problem, dass Dein Rechner nicht eindeutig angesprochen werden kann. Unter der Adresse existiert eben nur der Router. Und alles, was dahinter ist, ist ein ganz eigenes Netzwerk, die Adressen also nicht von außen auflösbar. Heißt: P2P-Daten enden am Router.
Und jetzt kommt's: Seinerzeit unterhielt mcdu.com, die Macher des FSInn, einen Resolver, der weiltweit für alle FSInn-Clients in allen Netzwerken die Adressauflösung erledigt hat. Eine ziemlich komplexe Geschichte, die auch für mich technisch nicht nachvollziehbar ist. Leider ist das FSInn-Projekt heute an Masse. Mcdu.com hat aufgegeben und seine Server (auf denen auch der Resolver lief) abgeschaltet Somit ist eine Adressauflösung für P2P hinter Routern heute nicht mehr möglich bzw. nur mit einem Kunstgriff, der aber vom Betreiber des Multiplayer-Netzwerkes eingerichtet werden muss.
Nun wird man entgegen halten, dass ja dennoch, also auch heute noch, ein P2P-Status im InnPlane (PLA) durch gelben Doppelpfeil angezeigt wird. Das steht auch, aber eben leider nur bis zum Router. Ab dort gibt es (unter P2P) keinen Datenaustausch mehr. Dummerweise wird das nicht abgeprüft und so geht das System davon aus, dass die vorhandenen Daten (meistens 0) korrekt sind. Das wiederum führt zu kuriosesten Effekten. Zum Beispiel, wenn der relative Abstand des Flugzeugs zu einem anderen abgefragt wird. Der mag tatsächlich ein paar Meilen betragen, aber der zurückgegebene Abstand beträgt 0. Das führt dann dazu, dass ein Flugzeug mit 0 Abstand unterwegs ist, also an einem zu kleben scheint. Schlimmer noch: Da in einem P2P-System jeder Client auch gleichzeitig Server ist, verarbeitet und verteilt der auch die Daten für andere und nicht nur die eigenen - mit dem Erfolg, dass auch ein ganz anderer Teilmehmer falsche Daten für einen noch wieder anderen Teilnehmer bekommt.
Nehmen wir mal an, dass wir ein Netzwerk aus 5 Clients hätten, von denen 4 NICHT über einen Router verbunden sind. Die Daten für alle laufen nun aber auch über Nummer 5, also den Kameraden, der hinter einem Router steckt. Nun werden die anderen 4 mit falschen Daten gefüttert und ALLE haben nun wenig lustige Effekte wie ungenaue Positionierungen, springende Flugzeugen oder Flugzeuge, die am eigenen zu kleben scheinen. Loggt sich nun der Router-Kollege aus, sind die Effekte schlagartig vorbei, weil dieser nun das Netzwerk nicht mehr mit krummen Daten versorgt.
Komischerweise aber funktioniert es dennoch einigermaßen, also scheinen bestimmte Parameter ja noch zu stimmen. Das liegt aber daran, dass der zentrale Server zwar beim P2P weitestgehend umgangen wird, aber dennoch über eine Reihe von Daten verfügt, die er zur Verwaltung braucht und die über das "normale" System kommen. Diese rudimentären Daten werden auch an die Clients durchgereicht, sodass Basics vorhanden sind, aber immer wieder durch wirre P2P-Daten verfälscht werden.
BTW: Der normale, non-P2P Datenaustausch funktioniert (auch heute noch) einwandfrei!!! Und kurioserweise ist genau dieser Umstand schuld, dass das P2P-System nicht bemerkt, dass da nur ein Router und kein echter Client mit den Daten umgeht. Das System weiß nämlich über das normale System, dass da ein Client unter der Adresse ist. Schließlich ist der ohne P2P ja einwandfrei ansprechbar. Und so hat man es sich erspart, das unter P2P noch einmal zu hinterfragen, und so wird der vermeintlich Clent munter verwendet, obwohl er eigentlich nur wirres Zeug von sich gibt.
Wenn Du nun schaust, wo sich im Setup des FSInn diese UPnP-Abfrage befindet (eben unter Peer to Peer), dann wird deutlich, dass UPnP nur für P2P benötigt wird. Und da, wie beschrieben, P2P nicht mehr wirklich funktioniert, wirst Du auch keinen UPnP-Status mehr erhalten. Vergiss ihn einfach. Das ist Geschichte und wird es auch bleiben, denn es ist nicht zu erwarten, dass mcdu.com noch einmal wieder Fahrt aufnehmen wird.
Bei vGAF verwenden wir allerdings einen Trick. Nachdem wir die Ursache für dumme Effekte unter P2P erforscht hatten (das hat Monate gedauert, insbesondere bedingt durch einige User, die uns mit ihrer Firewall monatelang an der Nase herumgeführt haben), haben wir uns überlegt, ob es einen Weg gibt, Router zu umgehen bzw. zu tunneln. Und so etwas haben wir gefunden, indem wir ein VPN eingerichtet haben. Dazu muss der User lediglich eine weitere Software installieren und einrichten, die ihn an dieses VPN anbindet. Nunmehr fliegen wir gewissermaßen nicht mehr über das WAN, sondern in einem LAN, das aber die Leitungen des WAN nutzt. Technisch verhält es sich ungefähr so, als seien alle beteilgten Rechner im selben Haus. Das VPN tunnelt Router komplett, ganz so, als seien sie gar nicht vorhanden. Das hat ein bisschen was von "Teufelswerk", klappt aber. Denn so befinden sich alle Clients im selben Adressraum.
Kompliziert? Ja, finde ich auch. Und erhrlich, das habe ich auch nicht an einem Nachmittag herausgefunden, sondern ist das Ergebnis monatelanger Experimente am offenen Herzen. Das muss man als User wohl auch nicht unbedingt wissen und kann sich darauf beschränken, es zu nehmen, wie es ist. Nur wann immer ich jemandem sage, dass P2P im FSInn nicht mehr existent ist, glaubt mir das kein Mensch und kommt mit irgendwelchen Gegenargumenten, die vermeintlich logisch sind, aber zu ewigen Diskussionen führen. Das schließt auch manchen Betreiber eines FSD-Servers ein, der voller Stolz einen Server ausgesetzt hat und betreibt, aber sich nicht mit den Hintergründen beschäftigt hat.
Was bleibt für Dich?
Du kannst FSInn nutzen! Aber ohne P2P! Und das funktoniert eigentlich recht gut. Auch und gerade ohne P2P ist FSInn netzwerktechnisch schon ein ziemliches Kuriosum, das sich fast überall durchmogelt. Allerdings sollte man FSInn auch dann möglichst wenige Hindernisse in den Weg stellen. Zusätzliche Firewalls und Security-Suiten sind auf jeden Fall immer eine Bremse und bedeuten manchmal eben auch das endgültige Aus für den Datenaustausch. Davon gehe ich bei Dir aber nicht aus, da es ja zu funktonieren scheint. Nur solltest Du P2P konsequent deaktivieren.
Ich muss auch noch hinzufügen, dass ich mich mit VATSIM überhaupt nicht auskenne. Bei der schieren Größe des Netzwerkes könnte ich mir vostellen, dass die eine Möglchkeit gefunden haben, P2P nutzen zu können. Nur müssten die dann ein komplettes Resolving aufgebaut haben, wie es seinerzeit bei mcdu.com war. Und wenn das so wäre, dann müssten irgendwo in einer cfg entsprechende Adressen für diesen Resolver eingetragen werden. Würden sie mit einem VPN arbeiten, müsste auch ein entsprechender Client installiert werden. Und davon habe ich auch noch nichts gehört.
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »vETNH« (11. Februar 2012, 16:34)