Zum PlayerInterface

Um nochmal auf das Topic zurück zu kommen.

traceAndComputeMove(Coord) macht keinen Sinn!
Wenn [der Kunde] das offen mit uns besprochen hätte, wäre das zu verhindern gewesen.[/code]

Ja. Wenn da nicht die acht anderen externen Software-Dienstleister wären mit deren Komponenten man interagieren muss und die ihre Protokollspezifikationen tatsächlich ständig gerne ändern (nicht unbedingt unberechtigt, Anforderungen der Fachabteilung ändern sich ja auch), dann hättest Du tatsächlich Recht.

(Und ich müsste Weihnachten nicht durcharbeiten)

Und genau das finde ich die sinnvollste Erweiterung. Wir haben uns das miteinander überlegt, und sind zu diesem Schluss gekommen. Es geht schlicht darum, dass nicht gecheatet werden kann... das ist doch im Sinne des Entwicklers und Betreibers. Und von der Implementierung her ist das eine zwei-Zeilen-Funktion, ich wüsste nicht warum man sich darüber aufregen sollte...

Hier nochmal eine allgemeine Antwort (an alle):

• Das PlayerInterface ist nur eine Protokollspezifikation, ihr könnt es ändern, wie ihr wollt (bis hin zu dem Extrem, dass man gar kein Interface verwendet). EDIT: So lange es wie vorgesehen mit anderen Servern bzw. Clients zusammenarbeitet.
• Zum Entstehungsprozess: ich habe in den Semesterferien selbst alles programmiert (Server, Client etc., TicTacToe + Reversi) um wirklich alle Probleme zu verstehen. Daraus ist das Interface entstanden.
• Die perfekte Spezifikation ist eine komplette Illusion. Propaganda in dieser Richtung wird gerne auch in akademischen Kreisen betrieben. Tatsache ist: Man programmiert etwas, probiert es aus und kommt auf komplett neue Dinge. In unserem Fall: das Ur-Interface würde es nach wie vor tun, aber es kam Feedback von Euch und von den Tutoren, so dass ich es (als normalen Teil des Entwicklungsprozesses) berücksichtigt habe. Die Änderungen waren doch alle relativ gering. Wo gab es Probleme? Diese Art von Änderung arbeitet nicht gegen die Aufgabenstellung, sie ist die (bzw. Teil der) Aufgabenstellung.

Jo2 hat Folgendes geschrieben:

Da ist aber ein kleiner unterschied. Weil da können wir eben so (den Code, wohlgemerkt!) ändern, wie wir wollen, um die Vorraussetzungen des Kunden zu erfüllen (was ja meistens Oberflächlichkeiten sind). Der sagt was man machen soll, was er noch haben oder nicht haben will. Aber er sagt nicht: "Euer Code muss so sein!" (Und das Interface macht nichts anderes, als uns in solche Sachen reinzuzwingen. Das kann man natürlich nur rausfinden, wenn man sich mit der Sache beschäftigt, und genau darum geht's ja.) Dann kann er's doch auch gleich selber machen? Und tatsächlich gibt es einige Leute in diesem Praktikum, die davon ein Liedchen singen können, wie es in der Wirtschaft aussieht

Vergesst nicht, dass es im Praktikum ein Dutzend Gruppen gibt. Sie implementieren alle das selbe. Ihre einzelnen Lösungen sollen alle miteinander kommunizieren können. Es ist also NICHT möglich, dass eine Gruppe sich ihre eigene Spezifikation ausdenkt. Eine höhere Instanz ist also Notwendig, die den Weg zu einem gewissen Grad diktiert.

Trotzdem kann es in der Wirtschafft durchaus zu ähnlichen Situationen kommen. Es ist nicht selten, dass mehrere Unternehmen gemeinsam an einem Projekt arbeiten. die Spezifikationen werden gemeinsam ausgearbeitet, und die Kommunikation ist langsam. Die einzelnen Gruppen kommen sich manchmal in die Quere, weil sie unterschiedliche Vorstellungen haben. Spezifikationen müssen im nachhinein angepasst werden, usw.

Wenn man das Praktikum also mit der Wirtschaft vergleichen will, dann nur mit solchen oder ähnlichen Situationen.

Danke, die Konstante ist tatsächlich überflüssig, die offizielle Version habe ich auch entsprechend verbessert.

Der Timeout soll am Server je nach Belieben eingestellt werden können, von daher ist eine Konstante nicht so sinnvoll.

Wie sehen denn n-Teilnehmer-Spiele in Reversi aus? Pro Spiel gibt es doch immer genau 2 Gegner(?)

Man bewirkt durch die Erweiterung, dass der Gegner schon einen Aufruf vor computeMove *genau* weiss, was er zu tun hat und schon vorausberechnen kann. Das ist eine von mehreren Möglichkeiten, wir haben uns für diese entschieden.

Globetrotter hat Folgendes geschrieben:

Also die ständigen Änderungen an der grunsätzlichen Architekur und am PlayerInterface sind unnötiger Aufwand und nerven irgendwie. Sowas hätte doch in einem ordentlichen Konzept bereits vorher festlegt werden können, statt hinther zu sagen, dass es ja so zum Beispiel für Cheating anfällig ist. Genauso unsinnig ist es ja auch computeMove nur einmal auszuführen, weil ist der Ping auch nur irgendwo im Netzwerk wegen mehr Traffic höher sein kann, fällt man aus dem Zeitfenster, das sicher sehr gering sein wird... Und sollte es zum Beispiel 1 Sekunde nur sein und wegen höhrem Netzwerk Ping dann verlieren ...da gehört auch eine regemäßige computeMove Übertragung her und am Ende der Zeit wird der letzte noch erhaltene Zug einfach genommen. Ansonsten gibst eigentlich noch weitere Cheat Einschränkungen wie Verbot von Datenbanken oder Netzwerkanbindung an Datenbanken...??

So ziemlich alle Offline-Dinge sind erlaubt (es gibt gute Pure-Java embeddable Datenbanken, aber die einzusetzen kostet Zeit und das kann man sich nur beim Programmstart erlauben), Netzanbindung nicht.

Wow. Hatte sich vorher jemand über zu viel Programmieraufwand beschwert?

Wenn wirklich jemand eine C-Lösung macht, würde ich das akzeptieren, alleine, weil ich es spannend finde zu sehen, wie die sich schlägt. Die Teilnahme ist dann ausser Konkurrenz (sprich: der Gewinner kann nur ein Java-Programm sein).

Der Kunde weiß am Anfang oft nicht genau, was er will. Mir fallen drei Möglichkeiten ein, wann so eine Sicherheitslücke entdeckt werden würde:

1.)
Das Spiel wird mit Sicherheitslücke implementiert. Das Spiel geht online. Nach kurzer Zeit tauchen Cheats auf. Eine Änderung der Spezifikation ist notwendig.

2.)
Beim ersten Gespräch zwischen Kunde und Entwickler, weist der Entwickler den Kunden sofort auf eine mögliche Sicherheitslücke hin. (Das wäre eure Aufgabe gewesen)

3.)
Dem Kunden oder dem Entwickler fällt während der Entwicklung die Sicherheitslücke auf. Eine Änderung der Spezifikation ist notwendig. (So ist es jetzt im Praktikum geschehen)

Es ist schwer alle Sicherheitslücken von Anfang an zu bedenken. Außerdem spielt im Praktikum die Komplexität der Spezifikation eine große Rolle. Es muss ein Kompromiss zwischen Sicherheit und Komplexität gefunden werden. Dies ist keine triviale Aufgabe, und kann vor Beginn des Praktikums nicht einfach gefunden werden. Erst im Gespräch mit Tutoren und Studenten lässt sich der Beste Weg finden.

Danke.

Aber nochmal zu dem Timeout: Das Spielzug-Timeout mag ja beim Server allein sinnvoll sein dafür gibts ja einen Parameter, aber das Timeout für eine OK-Antwort bzw die Regeln, den Namen o.ä.... interessiert das nicht den Client auch? (unter der Annahme dass das Interface bei beiden von uns geschriebenen Anwendungen das selbe ist und alles was dort definiert wurde, in der Dokumentation öffentlich zugänglich für evtl "fremde" Clients ist). Und Parameter gibts dafür ja keinen..

Und allgemein: gehören Timeouts nicht irgendwie auch zum Protokoll? Weil unter Umständen hängen Entscheidungen davon ab..
z.B. ob man den User vor Verbindungsaufbau nach dem Namen fragen muss, oder ob er ein paar Tage Zeit hat selbigen einzugeben, während die Verbindung offen steht, etc.

Marianne Busch hat Folgendes geschrieben:

Danke. rauschma hat Folgendes geschrieben: Der Timeout soll am Server je nach Belieben eingestellt werden können, von daher ist eine Konstante nicht so sinnvoll. Aber nochmal zu dem Timeout: Das Spielzug-Timeout mag ja beim Server allein sinnvoll sein dafür gibts ja einen Parameter, aber das Timeout für eine OK-Antwort bzw die Regeln, den Namen o.ä.... interessiert das nicht den Client auch? (unter der Annahme dass das Interface bei beiden von uns geschriebenen Anwendungen das selbe ist und alles was dort definiert wurde, in der Dokumentation öffentlich zugänglich für evtl "fremde" Clients ist). Und Parameter gibts dafür ja keinen.. Und allgemein: gehören Timeouts nicht irgendwie auch zum Protokoll? Weil unter Umständen hängen Entscheidungen davon ab.. z.B. ob man den User vor Verbindungsaufbau nach dem Namen fragen muss, oder ob er ein paar Tage Zeit hat selbigen einzugeben, während die Verbindung offen steht, etc.

Stimmt. Generell sollte der Client so wenig wie möglich über Timeouts und Netzwerk-Latenz wissen. Bei nicht-compute()-Methoden bedeutet dies: Seinen Job so schnell wie möglich erledigen und wieder zurückkehren (=> Namen vorher vom Spieler abfragen). Bei compute()-Methoden hat man zwei Timeouts: Einerseits die Berechnung -- hierauf muss sich der Client voll einstellen, das ist erwünscht und Teil des Protokolls. Andererseits die Netzwerk-Latenz, die man in der Tat momentan als Client noch kennen muss, um das Berechnungslimit richtig einschätzen zu können (indirekt spielt die Latenz auch bei nicht-compute()-Methoden eine Rolle, da man deren Timeout grosszügig genug wählen muss, dass genug Spielraum für die Latenz vorhanden ist).

Als Abhilfe werde ich dazu in den offiziellen Server folgendes einbauen (und -- sobald ich es komplett fertig und verstanden habe -- dokumentieren): Am Anfang wird die Netzwerk-Latenz geschätzt und dann zum Berechnungslimit (compute()-Methoden) bzw. Aufruf-Limit (nicht-compute()-Methoden) hinzugezählt. Damit muss man den Client nur noch vom Berechnungslimit informieren und kann ihn gegenüber den anderen Timeouts (der Einfachheit halber) im Dunklen lassen. Damit kann ich bei mir alles korrekt abdecken.