• Aktualisierte Forenregeln

    Eine kleine Änderung hat es im Bereich Forenregeln unter Abschnitt 2 gegeben, wo wir nun explizit darauf verweisen, dass Forenkommentare in unserer Heftrubrik Leserbriefe landen können.

    Forenregeln


    Vielen Dank
  • Kritk / Fragen / Anregungen zu Artikeln

    Wenn ihr Kritik, Fragen oder Anregungen zu unseren Artikeln habt, dann könnt ihr diese nun in das entsprechende Forum packen. Vor allem Fehler in Artikeln gehören da rein, damit sie dort besser gesehen und bearbeitet werden können.

    Bitte beachtet dort den Eingangspost, der vorgibt, wie der Thread zu benutzen ist: Danke!

Diablo 3 Test: PC Games testet Blizzards neues Hack'n'Slay-Epos

Gab es diese Diskussion nicht bereits beim Ubilauncher?

Meiner Meinung nach sollte man ganz explizit auf 'always on' und die Risiken hinweisen, z.B. "mobiles Zocken aufm Laptop im ICE wird schwerlich möglich sein".

Ansonsten sollte man wirklich nur das Spiel selbst bewerten ... wenn die Loginprobleme aber anhalten sollten, also nicht nur am Releasetag sondern es auch Tage danach noch zu Problemen kommt, dann sollte man das durchaus in eine Note miteinfließen lassen.

Denn technische Schwierigkeiten, seien es nun Bugs o.ä., können den Spielspass durchaus stören ... =)

Das ist ja auch richtig so. Was ich sagen wollte, ist einfach und schlichtweg, dass man ein Spiel nicht abwerten sollte, wenn zum Release Loginprobleme bestehen. Das ist völlig normal und üblich. Und ich kenne keinen Entwickler, der sowas nicht ein oder zwei Tage nach Release wieder in den Griff bekommen hat. Wenn diese Probleme dauerhaft bestehen, ja dann sollte es in die Wertung einfließen.

@ krucki1
Wie in den oberen Zeilen schon gesagt... ;) Keine weiteren Worte.
Und komm mir doch nicht mit diesem Apfel/Birne-Vergleich.

Eine Abwertung wäre nachvollziehbar, wenn NIEMAND auf die Server zugreifen kann. Aber das ist nicht der Fall.
 
Zuletzt bearbeitet:
:confused:

Bei den Texten von dir und TheChicky kommt mir immer folgender Begriff in den Sinn:

"rocket science"

Warum soll man die serverseitige Software nicht einfach auslagern können? Die Blizzardserver laufen auf einem Unixsystem, die Amazon EC2 Server auch? Es gibt einen "relativ" weit entwickelten b.net Emulator, der Sourcecode ist keine 100kb groß. :B

Das kontrollierte Abfragen von Accountinformationen von den Blizzardservern dürfte weniger Last und Datenverkehr verursachen, als wenn hunderttausend oder mehr Spieler fast zeitgleich sich verbinden wollen.

Das ist ja gerade der Sinn vom Amazon.de Dienst, dass diese Verbindungsanfragen, dadurch verursachte Last auf den Servern und der Internetverbindung von den Amazon Servern und deren Datenleitung abgefedert werden, und nur 'ernsthafte' Verbindungsanfragen weitergereicht werden.
 
:confused:

Bei den Texten von dir und TheChicky kommt mir immer folgender Begriff in den Sinn:

"rocket science"

Warum soll man die serverseitige Software nicht einfach auslagern können? Die Blizzardserver laufen auf einem Unixsystem, die Amazon EC2 Server auch? Es gibt einen "relativ" weit entwickelten b.net Emulator, der Sourcecode ist keine 100kb groß. :B

Das kontrollierte Abfragen von Accountinformationen von den Blizzardservern dürfte weniger Last und Datenverkehr verursachen, als wenn hunderttausend oder mehr Spieler fast zeitgleich sich verbinden wollen.

Das ist ja gerade der Sinn vom Amazon.de Dienst, dass diese Verbindungsanfragen, dadurch verursachte Last auf den Servern und der Internetverbindung von den Amazon Servern und deren Datenleitung abgefedert werden, und nur 'ernsthafte' Verbindungsanfragen weitergereicht werden.

- Nur weil beide System Unixoid sind, heißt das nicht, dass man bestehende binaries (also "kompilierten, ausführbaren Quelltext") beliebig hin und her switchen kann. Grade bei performancekritischen Applikationen sind OS/Architektur spezifische Optimierungen an der Tagesordnung. Es geht ja schließlich darum "das letzte rauszuholen". Ein Grad an Kompatibilität, wie du den schilderst, kann man schlichtweg einfach nicht annehmen, bzw. wäre wahrscheinlich (und hier spreche ich mit mehrjährigem Background als Software Developer) ein enormer Aufwand. Es sind schlichtweg sehr viele Faktoren, die da mit reinspielen.

- Es gibt vielleicht einen Emulator, der gewisse Teile der serverseitigen Implementierung des Battle.Net emuliert, aber die Frage ist dann auch, wieviel davon tatsächlich implementiert bzw. was dieser Emulator tatsächlich kann. Wenn man hingeht und mit einem Tool wie Wireshark den Traffic snifft, den Diablo 3 generiert richtung Battle.Net und das entsprechend analysiert, dann wäre es z.B. möglich durch Modifikation der hosts Datei den Traffic auf den eigenen Rechner umzuleiten und da mit irgendeiner Software darauf zu reagieren. Man könnte sich z.B. ein Python Script vorstellen, dass per socket Modul auf solche Anfragen reagiert und dann darauf replied, die Frage ist allerdings, inwiefern das sinnvoll wäre, bzw. was es bringt?! Vielleicht wäre es machbar dem Client zu verklickern "Hey, alles cool, hier ist das Battle.Net fahr mal fort mit deinem Startvorgang" oder "Hey die Login-Credentials sind okay" aber viel mehr dürfte da nicht drin sein. Das Backend einer Applikation wie dem Battle.Net ist definitiv sehr komplex und im Endeffekt durch die Tatsache, dass es auf einem entfernten System ausgeführt wird, schlichtweg sehr schwer zu "reverse-engineern". Weiterhin: Eine Größenangabe wie 100kb sagt schlichtweg nichts aus.

- Die Anfragen an das jetzige Battle.Net sind ja auch "ernsthafter" Natur. Der ungefähre (meinerseits vermutete Ablauf) derzeit sieht ungefähr so aus (am Beispiel "überprüfen von Login credentials" und unter Annahme, dass die Architekur "quasi-Standards" folgt):

Client (euer PC) -(request)-> Loadbalancer (irgendein Rechenzentrum von Blizz) -(forwarded request an app server)-> Application-Server (führt Battle.Net Software aus) -(baut connection zu db server auf)-> Datenbank-Server (checked Benutzername und Passwort gegen Werte aus der Datenbank)

Das Ergebnis wird dann entsprechend durch alle Schichten zurückgereicht und am Ende sagt der Client dann "Hey cool! Bro du bist eingelogged" oder "Möp! Passwort falsch". Bei jedem dieser Schritte ist theoretisch ein Timeout und damit ein Fehler durch Bottlenecks aufgrund massiven Ansturms möglich.

Würde man nun noch Amazon EC2 Server dazwischenpacken, bzw. würde was an dieser Struktur ändern, würde das nur mehr Chancen für Timeouts und Probleme geben. Im Endeffekt MUSS jede Anfrage am Ende des Tages im Cluster von Blizzard landen.
 
Zuletzt bearbeitet:
Nur hätte man auf externe Dienstleister zurückgreifen können, um eben besagten Ansturm abzufangen. Man hätte, als Beispiel, auf Amazon Web Service setzen können, um dem Ansturm Herr zu werden und nach vier Wochen die Daten mit einem Nachtlauf auf die eigenen Server bzw. Datenbestände migrieren können.

Hätte halt nur Geld gekostet ... und Amazon EC2 kostet nicht wirklich viel. :|

Vllt. mag sich ja TheChicky vllt. zu diesem Thema äußern. :top:

%)

Ach nöö, ich beobachte lieber, wie du dich selber blamierst.

Das B.Net auf Amazon Webserver ausweiten....da spricht der Fachmann :B
 
Ach nöö, ich beobachte lieber, wie du dich selber blamierst.
In Ordnung, allerdings ...

Das B.Net auf Amazon Webserver ausweiten....da spricht der Fachmann :B
... schein ich die Texte wenigstens aufmerksam zu lesen. :]

Das Angebot von Amazon nennt sich "Amazon Web Services", hat aber nichts mit Webserver zutun. Sondern Amazon stellt skalierbare Umgebungen mit div. Betriebssystemen bereit, d.h. div. Unix Versionen und natürlich auch Windows Server.
 
Erstmal vielen Dank für deinen Text. :top:

Mir fehlt jetzt leider die Zeit auf denen kompletten Text einzugehen, auch wenn ich dies gerne machen würde und die Tage ggf. nachhole!

Ich beziehe mich jetzt lediglich auf deinen letzten Teil des Beitrages:

Client (euer PC) -(request)-> Loadbalancer (irgendein Rechenzentrum von Blizz) -(forwarded request an app server)-> Application-Server (führt Battle.Net Software aus) -(baut connection zu db server auf)-> Datenbank-Server (checked Benutzername und Passwort gegen Werte aus der Datenbank)

Genau darum ging es mir. Dass die Server, die, vereinfach gesprochen, die BattleNet Software ausführen, zusammengebrochen sind. Sei es durch hunderttausende Anfragen pro Sekunde, unter der produzierten Bandbreite was auch immer ... wenn man jetzt dieses "Frontend", der Begriff ist falsch, ich weiß, ausgelagert hätte, auf eine Plattform mit deutlich mehr Ressourcen im Sinne von Bandbreite und ähnliches, hätte man hier die meisten Probleme abfedern können ... denn ich kann mir schwerlich vorstellen, dass die Datenbankserver im Hintergrund zusammengebrochen sind.

Der Rest von deinem Ablauf würde ja so bleiben, die DB Server senden ihr ACK Paket an die ausgelagerten Server, die wiederum senden das Okay an den Client.

Selbst mit deiner, zugegebenen besseren, technischen Erklärung sehe ich hier kein Grund, warum das so nicht funktionieren sollte.
 
Erstmal vielen Dank für deinen Text. :top:

Mir fehlt jetzt leider die Zeit auf denen kompletten Text einzugehen, auch wenn ich dies gerne machen würde und die Tage ggf. nachhole!

Ich beziehe mich jetzt lediglich auf deinen letzten Teil des Beitrages:

Client (euer PC) -(request)-> Loadbalancer (irgendein Rechenzentrum von Blizz) -(forwarded request an app server)-> Application-Server (führt Battle.Net Software aus) -(baut connection zu db server auf)-> Datenbank-Server (checked Benutzername und Passwort gegen Werte aus der Datenbank)

Genau darum ging es mir. Dass die Server, die, vereinfach gesprochen, die BattleNet Software ausführen, zusammengebrochen sind. Sei es durch hunderttausende Anfragen pro Sekunde, unter der produzierten Bandbreite was auch immer ... wenn man jetzt dieses "Frontend", der Begriff ist falsch, ich weiß, ausgelagert hätte, auf eine Plattform mit deutlich mehr Ressourcen im Sinne von Bandbreite und ähnliches, hätte man hier die meisten Probleme abfedern können ... denn ich kann mir schwerlich vorstellen, dass die Datenbankserver im Hintergrund zusammengebrochen sind.

Der Rest von deinem Ablauf würde ja so bleiben, die DB Server senden ihr ACK Paket an die ausgelagerten Server, die wiederum senden das Okay an den Client.

Selbst mit deiner, zugegebenen besseren, technischen Erklärung sehe ich hier kein Grund, warum das so nicht funktionieren sollte.

Bedenke bitte folgende 2 Faktoren:

- Die von mir in frage gestellte Kompatibiltät zwischen den Maschinen von Blizzard/der Battle.Net Software und den Amazon Maschinen (erster Absatz meines vorherigen Posts)
- Denke mal einen Schritt weiter und schau, was passieren würde, wenn man deinen Vorschlag umsetzt. Plötzlich bekommen alle Clients direkt und ohne Probleme eine Connection auf nen "App-Server"... Und was dann? Plötzlich landen wesentlich mehr requests bei der Datenbank und alles was passiert ist, dass sich der Bottleneck bzw. der "Ort" des Problems verschieben, weil die Datenbankserver bzw. die Datenbank nicht mehr hinterherkommt.

Tante Edith: BTW Weiß weder ich, noch du, noch irgendwer anders, der nicht bei Blizz arbeitet, WO letztendlich der Bottleneck von letzter Nacht aufgetreten ist. Dein Post suggeriert, dass es gesicherter Fakt ist, das die App Server weggebrochen sind. Das kann so allerdings niemand wissen (außer die Person arbeitet für Blizz).
 
Zuletzt bearbeitet:
Habe gerade meinen ersten legendären Gegenstand gefunden (orange Schrift). :-D :-D

Kann ihn aber NATÜRLICH nicht ausrüsten mit meiner Klasse. :(
 
Bedenke bitte folgende 2 Faktoren:

- Die von mir in frage gestellte Kompatibiltät zwischen den Maschinen von Blizzard/der Battle.Net Software und den Amazon Maschinen (erster Absatz meines vorherigen Posts)
Da du diese Maschinen nach deinen Wünschen anpassen, konfigurieren und Software installieren kannst, wüsste ich ad hoc jetzt nicht, woran die von dir angesprochene Kompatiblität scheitern könnte.

- Denke mal einen Schritt weiter und schau, was passieren würde, wenn man deinen Vorschlag umsetzt. Plötzlich bekommen alle Clients direkt und ohne Probleme eine Connection auf nen "App-Server"... Und was dann? Plötzlich landen wesentlich mehr requests bei der Datenbank und alles was passiert ist, dass sich der Bottleneck bzw. der "Ort" des Problems verschieben, weil die Datenbankserver bzw. die Datenbank nicht mehr hinterherkommt.
Habe ich, übrigens auch in schriftlicher Form ... ich meinte, ich kann mir kaum vorstellen, dass die Datenbankserver das Problem dargestellt haben. Schaut man sich die Fähigkeiten von z.B. NoSQL bzw. Redis an, dann werden verteilte Datenbankserver mit diesem Grundgerüst nicht wirklich ins Trudeln kommen.

Allerdings weiß ich nicht, was Blizzard nun wirklich als DB einsetzt.
 
Da du diese Maschinen nach deinen Wünschen anpassen, konfigurieren und Software installieren kannst, wüsste ich ad hoc jetzt nicht, woran die von dir angesprochene Kompatiblität scheitern könnte.


Habe ich, übrigens auch in schriftlicher Form ... ich meinte, ich kann mir kaum vorstellen, dass die Datenbankserver das Problem dargestellt haben. Schaut man sich die Fähigkeiten von z.B. NoSQL bzw. Redis an, dann werden verteilte Datenbankserver mit diesem Grundgerüst nicht wirklich ins Trudeln kommen.

Allerdings weiß ich nicht, was Blizzard nun wirklich als DB einsetzt.

Dann zitiere ich mich selbst:

- Nur weil beide System Unixoid sind, heißt das nicht, dass man bestehende binaries (also "kompilierten, ausführbaren Quelltext") beliebig hin und her switchen kann. Grade bei performancekritischen Applikationen sind OS/Architektur spezifische Optimierungen an der Tagesordnung. Es geht ja schließlich darum "das letzte rauszuholen". Ein Grad an Kompatibilität, wie du den schilderst, kann man schlichtweg einfach nicht annehmen, bzw. wäre wahrscheinlich (und hier spreche ich mit mehrjährigem Background als Software Developer) ein enormer Aufwand. Es sind schlichtweg sehr viele Faktoren, die da mit reinspielen.

Falls du mich vom Gegenteil überzeugen willst, dann nenn mir bitte deine Referenzen und an was für ner Art Projekten du bisher mitgearbeitet hast. Wenn man sich auch nur rundimentär in die Dokumentation eines C Compilers, wie z.B. gcc einliest und sieht was für Optimierungsmöglichkeiten (die zum gewissen Anteil immer plattformspezifisch sind) dann sollte es jedem Menschen mit ner Affinität für Technik möglihc sein zu erkennen, das so eine Kompatibilität nicht einfach "angenommen" werden kann.

NoSQL im Allgemeinen und Datenbanken, wie Redis, CouchDB oder MongoDB sind derzeit ein riesen Hype im IT Bereich, ja. Dieser neue Ansatz ermöglicht viele Probleme, die man mit relationalen Datenbanken hat, zu umschiffen (u.a. wesentlich simpleres Scaling), ja. Aber trotzdem ist das kein Grund anzunehmen, dass NoSQL Datenbanken nicht anfällig wären für Performanceeinbrüche wären. Eine stark frequentierte Instanz von MongoDB kann genauso in die Knie gehen, wie ein MySQL oder PostgreSQL oder was auch immer. Es ist schlussendlich ein anderer Ansatz der verfolgt wird, aber am Ende immer noch ein Stück Software.
 
Bin ich der Einzige, der hier arbeitet? :finger2:

Hier im Forum rumzuspammen nennstr DU ARBEITEN??? Echt, Du :wurst: :P

Also ICH war die letzten Stunden hier kaum aktiv da ich ein VBA Code optimiert habe.

Echt, tippt hier alle 3 Minuten nen neuen Post und nennt das dann arbeiten :S %) :B
 
:|

Ich hab halt meine fleißigen Bienchen, die das Geld erwirtschaften. Da bleibt dem Onkel Papa halt mehr Zeit für andere Dinge, wobei aber heute wirklich wenig los ist, jedenfalls für mich. :]
 
Ich hab halt meine fleißigen Bienchen, die das Geld erwirtschaften. Da bleibt dem Onkel Papa halt mehr Zeit für andere Dinge, wobei aber heute wirklich wenig los ist, jedenfalls für mich. :]

Hehe, das beweist meine These daß die Chefs weniger arbeiten und mehr verdienen als viele ihrer Mitarbeiter. ;)
 
ich gebs ungern zu aber mittlerweile bin auch ich 'gehyped'.
dabei hatte mich diablo 3 bislang eigentlich eher wenig interessiert. :-D
 
der name "diablo" bringt sowieso +70% und siehe man hat 93% xD
 
Da bin ich ja mal gespannt, wie weit die Einspannung in den Hype bei PCG noch geht. Wir werdens ja dann im Test erleben. Hoffentlich werden auch ein paar (oder gar alle) negative Kritikpunkte angesprochen, die dann auch Einfluss auf die Wertung haben. Aber wahrscheinlich ist sowieso jeder Kritikpunkt irrelevant, weil die ominöse Spielspaßkurve selbstverständlich ständig an der Decke hängt.
 
Zurück