Micha95 hat geschrieben:Danke schon mal für die Antworten!
@js:
Das mit den 2min hab ich aus ner Aussage von dir - wirklich viel detailierte Infos über die
Das muss aber eine sehr sehr alte Aussage sein. Wo soll die stehen, denn die gilt seit gut 4 Jahren so nicht mehr.
Arbeitsweise "hinter der Fassade" gibt's ja nicht bzw. war ich trotz rel. intensiver Forensuche noch nicht in der Lage zu finden. Evt. auch ein Grund warum die Fragen bzgl.
Das hat mehrere Gründe:
1. kaum einer will es wissen, dafür würde so eine Beschreibung, die jeder verstehen könnte, sehr viel Arbeit machen
2. es gibt immer mal wieder Änderungen, so dass diese dann nicht nur entwickelt und getestet sondern auch noch (für wenige Leser) dokumentiert werden müssten
Reconnects mit beständiger Regelmässigkeit wieder auftauchen. Ich verstehe, dass es Arbeit ist und wertvolle Zeit raubt eine kleine FAQ zu solchen Themen zusammenzustellen, aber evt. würde es mehr Zeit einsparen bei den häufigen Nachfragen. Die Stickies zum Thema sind zwar ein paar, aber alle relativ wage was Hintergrundinfos angeht.
Die Handbuch-Autoren sind für jede Hilfe dankbar. Die FAQ (
http://doku.stellwerksim.de/faq) kann nur so gut sein, wie die Zulieferung.
Es war mir bisher noch nicht mal möglich sicher herauszulesen was der Server über den Aufenthaltsort eines Zuges weiß - ob er weiß in welchem Stellwerk er ist oder nicht (mehr sowieso nicht) - bin mir ziemlich sicher, dass er es nicht weiß, sondern die Züge werden wohl mittels Verspätungsupdates daran gehindert ins nächste Stellwerk einzufahren. Der Fahrplan liegt also effektiv nur im Spiel selbst und nicht am Server vor - was aus Datentrafficsicht durchaus Sinn macht/machen könnte. Das kann alles völlig falsch sein, würde aber einige der "geht technisch nicht" Antworten erklären...
Nun, das ändert sich in schöner Regelmäßigkeit bei größeren Updates. Hinzu kommt, dass etliche Faktoren bewusst nicht öffentlich dokumentiert sind, um etwaige "Spielkinder" an ihrem Spieltrieb zu hindern, die sonst das System vielleicht lahmlegen könnten. Das würde nämlich dann bedeuten, dass entweder stärkere (und damit aufwändigere) Schutz- und Testmaßnahmen eingebaut werden müssten oder aber alles einfach den Bach runter gegangen lassen wird. Beides nicht toll.
Das System müsste eine abgebrochene Verbindung nicht selbst erkennen, das könnte der User theoretisch selbst per "Reconnet"-Button oder automatisch. Das Java-Spiel selbst stellt ja sofort fest, dass die Verbindung weg ist und wirft die Meldung aus, ergo könnte es in diesem Fall den Server versuchen neu zu kontaktieren, gibt ihm damit die neue IP und die Logindaten, womit sichergestellt ist, dass der User derjenige ist, der er vorher schon war.
Soweit die Theorie. Aber wie lange soll da gewartet werden? 1 Minute, 5, 10? Je länger gewartet würde, desto mehr staut sich auf. Und es bleibt die Frage: Wie soll das System das erkennen? Oder soll pauschal nach jedem Verbindungsabbruch (der gewollt oder ungewollt sein kann) 5 Minuten gewartet werden? Dann müssten die 10 Minuten Wartezeit auf 15 erhöht werden. Es müssten also alle, die ordentlich ein Spiel verlassen haben wegen weniger, die damit Probleme haben, 5 Minuten länger warten damit diese weniger lang warten müssen. Ist kein gutes Verhältnis.
Außerdem verlangt das nach einer aufwändigen Wiedererkennung. Denn auch der IRC-Server ist von plötzlichen Verbindungsabbrüchen nicht begeistert: Er bemerkt die auch erst nach bis zu 5 Minuten, weil die Gegenseite keine Antwort mehr schickt. Das heißt, der Spieler müsste mit einem anderen Namen auftauchen, dazu eine andere IP-Adresse. Und dann soll das System diesem "völlig fremden" nun glauben? Und eine DSL-Trennung ist auf Serverseite eine ziemlich rüde Sache: davon erfährt nämlich der Server überhaupt nichts! Statt dessen kann er nur warten und nach einer gewissen Zeit ohne Antwort davon ausgehen, dass da etwas nicht mehr da ist.
Der Server weiß damit das neue Ziel für seine Daten und die Verbindung steht wieder. Das scheint aber entweder seitens Java (bzw. der Verbindung Java/Browser) nicht zu gehen oder es ist nicht gewollt, dass das Spiel selbst die Logindaten schickt. Die
Verbindung selbst scheint ja nicht über das Spiel sonder nur über den Browser hergestellt werden zu können
Weiß er, wie oben erklärt, erstmal nicht. Die Logindaten, und damit zur nächsten Schwierigkeit, sammelt das Forum. Und das Forum schmeist auch erstmal jeden raus, der mit einer andere IP kommt oder sich mehr als 10 Minuten nicht mehr gerührt hat.
Das ist falsch, nach einem Reconnect müssen alle Programme ihre Verbindung neu aufbauen bzw ihren Request (z.B. Browser) mindestens einmal neu absenden, damit Antwortpakete zur neuen IP-Adresse auch ankommen.
Das seh ich ja genau wie du, nur eben versteh ich nicht, warum dieser resend nicht möglich ist - Problem der Verknüpfung Java/Browser, da ja das Spiel neustartet wenn man die Startseite neuläd oder geht der Connect vom Java-Spiel selbst nicht?
Da kommt das Sicherheitskonzept von Java-Applets zum Tragen, normalerweise zum Vorteil des Nutzers: Das Applet darf nicht mal eben irgendwelche Webseiten öffnen außer in dem Fenster, in dem es läuft. Das dumme dabei ist, dass das Applet damit die Seite ändert, auf der es läuft. Macht es schon klick? Die Seite, auf der das Applet läuft, wird neu geladen.
Wie gesagt: Der Nutzen, dass einige wenige Spieler ihr Spiel wegen ihrer schlechten Leitung wieder aufsetzen können steht in keinem Verhältnis zum technischen Aufwand und den Restriktionen, die für andere Spieler entstehen (siehe oben 15 statt 10 Minuten, Stauung des Verkehrs zu Nachbarn). Und selbst mit dem Aufwand ist eine Garantie der Funktion nicht gegeben, wie eine DSL-Trennung serverseitig zeigt.
Im übrigen: es gibt kein Online-Spiel, dass eine DSL-Trennung übersteht. Einzig die Wartezeit bei hoher Leistungsauslastung ist bei manchen Spieler da recht hoch. Bei Spielen wie World-of-Warcraft dürfte man selbst bei 1 Sekunde Verzögerung schon aus dem Spiel fliegen oder von irgend einem Monster erschlagen worden sein - keine Ahnung, reine Vermutung.
Du siehst, die Gedanken für eine Lösung und die Gründe für die jetzige Umsetzung habe ich mir schon vor Jahren gemacht. Es mag sicherlich die eine oder andere Umsetzungsmöglichkeit geben. Sie muss aber in einem angemessenen Verhältnis Aufwand-Nutzen stehen. Und der Nutzen ist einfach noch zu gering, denn selbst deine auf den ersten Blick durchaus umsetzbare Lösung (die mir auch gefallen hat) wird leider viele Fälle nicht abdecken - vermutlich schon deinen eigenen Problemfall nicht wegen der genannten serverseitigen Bedeutung der DSL-Trennung.
Hier würde eine Signatur stehen. Beachtet eh keiner, wozu also.
![R-Admin [Test-Manager]](./ext/sts/perms/styles/all/theme/images/radm_a.png "R-Admin [Test-Manager]")
Glaub ich aber auch nicht, denn Input ist ja erwünscht und dahingehend versteh ich auch deine Antwort.
![Qualitätssicherung [Zug-QS]](./ext/sts/perms/styles/all/theme/images/qs_a.png "Qualitätssicherung [Zug-QS]")