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.

Bei der Ton-Geschichte kann ich Dir auch nicht wirklich helfen. Wie gesagt, mit VATSIM habe ich nur kurze Bekanntschaft gemacht, die dann auch der Auslöser war, ein eigenes Netzwerk aufzumachen.

Wir nutzen zum Flugfunk Teamspeak separat. Hier kann man auch sehr schön dem TS ein eigenes Sound-Device zuweisen. So z.B. wenn man ein USB-Headset nutzt. Dann lassen sich die FS-Geräusche über die Desktop-Lautsprecher ausgeben und der Flugfunk über das Headset.

Eine ganz andere Frage ist: Warum willst Du unbedngt FSInn auf einem Zweitrechner laufen haben?

Ich hatte das früher auch so, musste dann aber feststellen, dass das irgendwie mehr für's Ego war als für einen praktischen Nährwert. Naja, zugegeben, es hat natürlich was, wenn sich die beiden Rechner wie "Teufelswerk" automatisch zusammenraufen....

OK, man kann dann sehr schön alle FSInn-Features auf dem 2. Rechner betrachten (was weiß ich, InnPlane, InnRadar etc.) und müllt sich dann nicht den FS-Screen zu. Aber braucht man das wirklich? Ein anderer Denkansatz wäre (so z.B. meiner damals), Ressoucenschonung für den FS-Rechner - eben durch vermeintliche Verlagerung der FSInn-Arbeit auf den Zweitrechner. Aber das ist ein Trugschluss. Zum einen braucht FSInn nur verschwindend geringe Ressourcen und zum anderen läuft FSInn bei einem Zweitrechner auf BEIDEN Rechner und mach dort so ziemlich dasselbe. Die Ressoucenschonung besteht dann eigentlich nur noch im Wegfall der Darstellung der GUI. Dafür aber hast Du eine erweiterte Netzwerk-Arbeit, denn darüber müssen sich dann zusäzlich beide FSInn-System koordinieren.

Also ich bin schon lange weg von Zweirechnersystem für FSInn.

Nun habe ich da natürlich leicht reden, weil ich hier mit 3 bis 4 Monitoren am Werke bin und daher alles wunderschön verteilen kann. Aber genau genommen habe ich kaum FSInn-Fenster offen. Meine Monitoren werden von etlichen FS-Fenstern, FSNav, TS und irgendwelchen 3rd-Party-Softwares befüllt. Und nur, weil ich als System-Admin sehen möchte/muss, was in meinem Netzwerk passiert bzw. wo Probleme auftauchen, ist InnPlane geöffnet.

Den Effekt mit dem fremden Flugzeug im Nacken hatte ich damals auch mal und wußte nicht, was das bedeuten sollte. Ich hielt es für den Scherz eines fremden Mitfliegers und versuchte zunächst zu entkommen.

Noch etwas zu Teamspeak. Wir benutzen wegen der besseren Sprachqualität mittlerweile Teamspeak 3 bei den Buschpiloten. Das Programm wird ebenfalls separat gestartet.

Hin und wieder fliegen wir auch mit einer anderen Gruppe plus Online-ATC. Dafür haben wir in FSInn eine vorgegebene Frequenz eingestellt. Wird diese gerastet, wird Teamspeak 2 automatisch gestartet. Die Unterhaltung zwischen den Piloten erfolgt weiterhin über Teamspeak 3. Den Unterschied merkt man an der Sprachqualität. Gibt der Controller eine andere Frequenz vor, wird diese im Flieger gewählt und TS2 läuft dann darüber weiter.

Zitat von »hhoelscher«

Den Effekt mit dem fremden Flugzeug im Nacken hatte ich damals auch mal und wußte nicht, was das bedeuten sollte. Ich hielt es für den Scherz eines fremden Mitfliegers und versuchte zunächst zu entkommen.

Es ist auch nicht ganz einfach zu verstehen, was dafür die Ursache ist. Und das führt oft dazu, dass der, der an anderen zu kleben scheint, auch dafür verantwortlich gemacht wird. Man geht eben davon aus, dass der auch der Verursacher ist und dann wird ihm vorgeworfen, er habe seine Firewall nicht vernünfitg eingestellt. Tatsache ist aber, dass es ein x-beliebiger Teilnehmer sein kann, der vielen ander sogar allen anderen die Effelkte beschert. Dabei ist es wurscht, ob er sich hinter einem Router verschanzt oder "nur" durch eine Firewall abgeriegelt wird.

Da gibt es übrigens noch so ein paar Dinger, um die man wissen sollte:

• Im FSInn beispielsweise gibt es eine Option "Internet Online Mode". Kaum einer weiß, was die bewirkt, aber das hört sich wichtig an und ist sowieso per default aktiviert. Also bleibt oder wird das auch aktiviert. Nur ist genau DAS die Funktion, die seinerzeit den Resolver von mcdu.com angesprochen hat. Und die läuft nun ins Leere.
  Man hat die Möglichkeit geschaffen, dies abzuschalten, weil FSInn ja auch in eigenständigen Netzwerken (LAN) laufen sollte, in denen kein Resolving stattfinden muss. Heute sollte man das tunlichst abschalten.
• Viele glauben auch, dass man es sich einfach machen kann in Bezug auf die Windows-Firewall, indem man sie einfach abschaltet. Zum einen würde ich niemandem dazu raten, wenn er nicht zusätztlich durch einen Router geschützt ist und zum anderen ist das nach unseren Erfahrungen zumindest bei VISTA und Win7 eher kontraproduktiv. Wir haben festgestellt, dass "Aus" nicht gleich "Aus" ist, und geben ganz klar vor, die Firewall NICHT auszuschalten, sondern nach unseren Vorgaben zu konfigurieren. Aber auch das ist etwas, was man offensichtlich den Wenigsten klar machen kann. Wie oft musste ich mir schon anhören "Nee, an meiner FW liegt es nicht, die ist ganz aus.....". Das ist dann immer der Moment, wo ich frage, was denn daran falsch zu verstehen sei, wenn wir in unseren Tutorials (Pflichtlektüre für vGAF-Piloteure) schreiben "NICHT DEAKTIVIEREN!!"
  
  Na klar, die FW ist dann deaktiviert, aber das bedeutet nur, dass ihre Überwachung der Vorgänge off ist. Die bis dato gemachten Einstellungen, was gesperrt wird und was nicht, bleiben aber erhalten. Zugegeben, das haben wir selbst anfangs nicht gewusst oder geglaubt. Diese Erkenntnis hat sich mehr oder weniger zufällig bei Experimenten ergeben.
• Paralleles surfen, downloaden oder gar Videos schauen via Youtube & Co. sollte man sich während eines Onlinefluges verkneifen. Auch dann, wenn man eine vermeintlich breitbandige Anbindung hat. Das Problem ist hier weniger die Bandbreite des Internetanschlusses als vielmehr das Netzwerk-Handling auf dem eigenen Rechner. Da werden Prioriäten zu Ungunsten des FSInn verschoben und dann bleiben Flugzeuge auch schon gern mal sekundenlang in der Luft stehen, um dann plötzlich mit unrealistischer Geschwindigkeit auf die eigentliche Position aufzuschließen. Und - wie so oft bei FSInn - das kann sich auf alle anderen auswirken, wenn der eigene Rechner unter P2P gerade Daten anderer vermitteln soll.
• Auch nicht netzwerknutzende, aber ressourcenlastige Programme, die man parallel laufen lässt, verschieben die Prioritäten. Wenn beispielsweise jemand schon mal im Hintergrund ein Video rendert, muss man sich nicht wundern, wenn man plötzlich fremde Flieger springen sieht und von den Mitfliegern Meldungen kommen, dass da irgendwas nicht stimmt. In dem Falle bekommt das Netzwerk nicht mehr die Priorität, die es braucht.
  
• Bei den Einstellungen der P2P-Geschwindigkeit ist weniger mehr!! Bis zu 40 hz, also 40 Datenupdates pro Sekunde können eingestellt werden. Aber das ist dann mehr was für's Ego (man hat ja schließlich reichlich Bandbreite, also will man die auch nutzen - auch wenn's nicht gebraucht wird!). Man beachte, dass unter P2P jeder mit jedem verbunden ist, Verbindungen gehalten und aufgebaut werden müssen. Je mehr Teilnehmer da sind, desto mehr ufert das aus und der eigentlich harmlose FSInn, der grundsätzlih sogar mit ISDN leben könnte, beginnt, das Netzwrk zu fordern. Hier lieber etwas zurücknehmen und max. 20 hz einstellen. Dadurch wird nicht ruckeliger, es entlastet aber das Netzwerk. Man beachte dabei, dass FSInn ja nicht allein am Wirken ist, sondern auch noch Audioverbindungen (ATC und allgemeines Geplauder) gehalten werden.
• Wetterupdate: Na klaaaaar, das lassen wir uns alle 5 Sekunden einspielen. Wir nehmen, was wir kriegen können. Als wenn sich das reale Wetter alle 5 Sekunden ändern würde. Dabei werden beim Wetterupdate richtig Daten geschaufelt. Unser METAR-Server spricht da Bände. Es KANN dabei soweit gehen, dass der FS alle 5 Sekunden einen kleinen Ruckler macht, der durchaus nervig ist. Das bekommt man auch schon mit dem FS2004 auf einer Hardware hin, die vor 3 Jahren noch state of art war, wenn man noch ein paar andere FS-Gimmicks wie FSNav etc. online laufen hat.
  Besser ist es hier, auf 300 Selunden zu stellen.

P2P ist eigentlich wohl DAS Feature, das den FSInn von anderen Clients abhebt. Nur leider ist es auch gleichzeitig eine kritische Geschichte, die durch den Wegfall von mcdu.com nicht eben besser geworden ist. Manchmal hilft es eben nur, es zu deaktivieren, wenn es mal bei einer Sitzung gar nicht recht will. Im Normalmodus ist die Darstellung zwar nicht so rund wie mit 20 hz unter P2P, aber auch wenig bis gar nicht anfällig. In dem Fall kommen die Daten nicht von irgendwelchen Clients, deren Besitzer gerade Gott wer weiß was veranstalten, sich hinter Routern tarnen, ihre Firewall irgendwie zurechtgefrickelt und das Ganze ohnehin mehr schlecht als recht zum Laufen bekommen haben. Vielmehr sind das dann Daten, die der eigentliche Zentralserver, der FSD, sammelt und zur Verfügung stellt. Zwar kann auch er nur mit Daten handeln, die er von wem auch immer bekommen hat, aber auf jeden Fall sind die zuverlässiger als das, was irgendwelche misskonfigurierten Clients da so von sich geben. Hinzu kommt, dass es dann auch keine Routing-Pobleme gibt, weil irgendein Client seiner Aufgabe als Waypoint nicht nachkommt. Der Datenweg ist dann ganz klar definiert, nämlich vom Client zum FSD-Server und zurück.

Worum ich mir nochmal Gedanken machen muss und irgendwann, wenn ich dazu komme, auch mal machen werde, ist das Aircraft Repository. Da bin ic mir niht so ganz sicher, ob FSInn da noch ein bisschen zu optimieren ist. Zum einen, was die Auflösung anderer Flugzeugtypen anbetrifft und zum anderen ist dort eine mcdu.com-URL abgelegt, von der ich nicht weiß, ob die genutzt wird oder nicht. Sollte FSInn da regelmäßig nachschauen wollen, wird er auch ins Leere laufen. Wie auch immer sich das auswirken mag. Aber bis dato konnte ich mich nochj nicht aufraffen, in die komplexe Materie einzusteigen. InnPlane ist da sowieso für mich eine Art rotes Tuch.

Zitat von »vETNH«

Zitat von »hhoelscher«

Den Effekt mit dem fremden Flugzeug im Nacken hatte ich damals auch mal und wußte nicht, was das bedeuten sollte. Ich hielt es für den Scherz eines fremden Mitfliegers und versuchte zunächst zu entkommen.

Es ist auch nicht ganz einfach zu verstehen, was dafür die Ursache ist. Und das führt oft dazu, dass der, der an anderen zu kleben scheint, auch dafür verantwortlich gemacht wird. Man geht eben davon aus, dass der auch der Verursacher ist und dann wird ihm vorgeworfen, er habe seine Firewall nicht vernünfitg eingestellt. Tatsache ist aber, dass es ein x-beliebiger Teilnehmer sein kann, der vielen ander sogar allen anderen die Effelkte beschert. Dabei ist es wurscht, ob er sich hinter einem Router verschanzt oder "nur" durch eine Firewall abgeriegelt wird.

das kann man ganz leicht lösen



Es sollten schon alle Teilnehmer dieses Häckchen gesetzt haben,dann gibt es dieses Problem nicht mehr.