[Bug] Auswahl der Hauptdatei

ZeroByte
Beiträge: 25
Registriert: Mi 14. Sep 2011, 21:08

[Bug] Auswahl der Hauptdatei

Beitragvon ZeroByte » Di 11. Okt 2011, 19:31

Moin,

bei mir tritt ein Problem beim Auswählen der Hauptdatei des Computerspielers auf.
Konkret werde ich auf diese Seite weitergeleitet, sobald ich auf "Auswählen" drücke:
http://134.245.253.5/saison/1/teams/335 ... elect_main

"The page you were looking for doesn't exist."

Die Datei hat keine Endung (wie für GCC eben üblich). Das hat aber mit diesem Problem anscheinend nichts zu tun, da ich die beiligenden Libraries ebenfalls nicht auswählen kann

Mit freundlichen Grüßen

ZeroByte
Beiträge: 25
Registriert: Mi 14. Sep 2011, 21:08

Re: [Bug] Auswahl der Hauptdatei

Beitragvon ZeroByte » Sa 22. Okt 2011, 16:31

Wenn wir grad schon alle am Nörgeln sind, dann will ich mal in nichts nachstehen ;P
Das Feature fehlt offenbar und kann in ziemlich genau 5 Minuten implementiert werden. (nach unten offen, versteht sich). Rafft euch auf, schließlich gehts grad erst wieder los ... ;)

(Hintergrund: boost::timer misst 1,2 sekunden laufzeit (all inklusive, sogar das Versenden der Antwort über das Socket), gleichzeitig kickt der Server mein Script, weil es angeblich länger als 2 Sekunden gebraucht hat. paradox. => boost::timer und wine scheinen sich nicht besonders gut zu verstehen. => habs nativ auf Ubuntu kompiliert. Und genau das kann ich jetzt nicht ausführen, weil die Auswahl der Hauptdatei schlicht fehlt. )

MfG

wollw
Beiträge: 31
Registriert: Mi 16. Mär 2011, 21:43

Re: [Bug] Auswahl der Hauptdatei

Beitragvon wollw » Mo 24. Okt 2011, 21:28

Möglicherweise ein anderer Bug, eventuell aber auch ein Hinweis auf das Verhalten des Servers zur Überprüfung der 2-Sekunden-Regel in dem anderen in diesem Thread beschriebenen Fall.

Folgende Situation:
Der Simple Client (Java) wird um eine Strategie erweitert.
Darin wird eine Klasse MyMove (s.u. [1]) verwendet, die von sc.plugin2012.BuildMove abgeleitet wird und zusätzliche Attribute und Methoden enthält.

In der Methode onRequestAction() des IGameHandler werden Objekte der Klasse MyMove gebildet und einer davon als BuildMove zurückgegeben (s.u. [2]). In diesem Fall reagiert der Server mit der Meldung einer Zeitüberschreitung. Mithilfe von wireshark wurde jedoch festgestellt, dass der Client die Antwort in weniger als einer Sekunde liefert. Die weitere Analyse des wireshark-Protokolls zeigt, dass auch die abgeleiteten Attribute aus MyMove mit dem xml-Stream mitgeliefert werden.

Ändert man die Implementierung nach [3] ab, reagiert der Server normal ohne Meldung einer Zeitüberschreitung. Die Analyse mit wireshark zeigt, dass der xml-Stream erwartungsgemäß nur die Attribute des BuildMoves enthält.

Meine Schlussfolgerung: Die durch die Library durchgeführte Serialisierung des Objektes führt bei Objekten von Subklassen, die gemäß Java-Spezifikation Objekte ihrer Superklassen ersetzen, zu einer fehlerhaften Interpretation des xml-Streams durch den Server. Wenn das so bleibt, müsste die Klasse sc.plugin2012.BuildMove final deklariert werden, damit keine Subklassen abgeleitet werden können.

Kai Wollweber
Peter-Ustinov-Schule


[1]
package sc.player2012.logic;
import sc.plugin2012.BuildMove;
public class MyMove extends BuildMove implements Comparable<MyMove>{
private int value;
public MyMove(int city, int slot, int size) {
super(city, slot, size);
value = 0;
}
@Override
public int compareTo(MyMove m) {
if (this.value > m.value) return -1;
if (this.value < m.value) return 1;
return 0;
}
[...]
}

[2]
@Override
public void onRequestAction() {
System.out.println("*** Es wurde ein Zug angefordert");
[...]
int city, slot, size;
[...]
MyMove m = new MyMove(city, slot, size);
[...Berechnung des optimalen Zuges...]
return m; //(mit Cast-Operator: return (BuildMove)m; wäre syntaktisch auch korrekt, führt auf den gleichen Fehler)

[3]
@Override
public void onRequestAction() {
System.out.println("*** Es wurde ein Zug angefordert");
[...]
int city, slot, size;
[...]
MyMove m = new MyMove(city, slot, size);
[...Berechnung des optimalen Zuges...]
return new BuildMove(m.city, m.slot, m.size);
Kai Wollweber
Peter-Ustinov-Schule
Eckernförde

ZeroByte
Beiträge: 25
Registriert: Mi 14. Sep 2011, 21:08

Re: [Bug] Auswahl der Hauptdatei

Beitragvon ZeroByte » Di 25. Okt 2011, 12:16

Moin,

Dein oben genanntes Problem würde ich definitiv als Bug bezeichnen - wenn der Server etwas nicht verarbeiten kann, darf er gerne mit einer Fehlermeldung antworten.

Ich habe jetzt noch einmal einen kompletten Log von einem fehlgeschlagenen Spiel (auf dem Server) erstellt (zur Laufzeit), hier die kritische Stelle:

- tmpRoot ist von keinerlei Bedeutung, nur ist es für die Verarbeitung von validem XML notwendig (mit XML-SP nicht, mit irrXML schon)
- ">>" kennzeichnet es, wenn mein Client etwas verschickt
- "Received Move Request" zeigt an, dass der Client eine Aufforderung erkannt hat
- die Zeitangabe "turn took total" gibt die Zeit an, die _insgesamt_ vom Empfang der Anfrage bis nach der Antwort vergangen ist

Code: Alles auswählen

<tmpRoot>
  <room roomId="7804f8d7-6d2b-45fc-9779-aaf822dcf732">
    <data class="memento">
      <state class="manhattan:state" turn="12" start="red" current="blue" type="build">
       [...]
      </state>
    </data>
  </room></tmpRoot>
<tmpRoot>
  <room roomId="7804f8d7-6d2b-45fc-9779-aaf822dcf732">
    <data class="sc.framework.plugins.protocol.MoveRequest"/>
  </room></tmpRoot>
Received Move-Request...
Took 0.12 seconds to determine best build!
>><room roomId="7804f8d7-6d2b-45fc-9779-aaf822dcf732" >

<data class="manhattan:build" city="0" slot="1" size="2" />

</room>


Turn took total 1.12 seconds.
<tmpRoot>
  <room roomId="7804f8d7-6d2b-45fc-9779-aaf822dcf732">
[...]
      <score cause="SOFT_TIMEOUT">
        <part>1</part>
        <part>0</part>
        <part>4</part>
        <part>1</part>
        <part>0</part>
      </score>
     [...]
    </data>
  </room></tmpRoot>


Den kompletten Log habe ich mal angehängt.

MfG

EDIT: Die Uploadfunktion funktioniert auch nicht. "Konnte Dateianhang nicht nach ./files/89_dd9e7d749e51a50127dc1d1e1ff41eda hochladen."

Dann eben per Pastebin

mind_in_a_box
Beiträge: 15
Registriert: Mi 31. Aug 2011, 19:26

Re: [Bug] Auswahl der Hauptdatei

Beitragvon mind_in_a_box » Di 25. Okt 2011, 15:40

Eine kurze Frage an dich, ZeroByte:

Ist es bei dir eigentlich auch so, dass du die XML-Daten nur in Stücken vom Server bekommst? Also, dass plötzlich mitten drin einfach abgebrochen wird und du den rest erst mit dem nächsten receive()-Aufruf bekommst?

Ich lasse im Moment TinyXML prüfen ob das XML-Stück korrekt ist oder nicht. Wenn nicht wird nochmal das Socket abgefragt. Ich denke aber nicht, dass dies so sein sollte, und schätze, dass es eher unsicher ist.
Was wenn doch mal ein fehlerhaftes Stück durch kommt? Oder der Server woanders einen Fehler einbaut? Dann wartet sich mein Client tot.

Vielleicht könnte sich einer der Server-Entwickler das mal anschauen oder wenigstens sagen ob das normal ist?

ZeroByte
Beiträge: 25
Registriert: Mi 14. Sep 2011, 21:08

Re: [Bug] Auswahl der Hauptdatei

Beitragvon ZeroByte » Di 25. Okt 2011, 17:07

Dass du die Daten in handlichen Päckchen bekommst, ist völlig normal. Das Problem ist hier, dass es keinen eindeutig definierten Delimiter gibt - das heißt rein theoretisch kannst du gar nicht feststellen, wann du alles gelesen hast, was der Server dir zu sagen hat.

Der Anhaltspunkt, den ich benutze, ist der room-Tag. Das funktioniert soweit wunderbar, auch wenn es natürlich designtechnisch alles andere als schön ist.

Normalerweise löst man sowas über SOAP, d.h. jeder Request an sich ist ein eigenes, valides XML-Dokument. Warum das hier nicht gemacht wurde, kann ich dir allerdings nicht sagen - vermutlich weil es ohne einfacher zu loggen ist.

MfG

mind_in_a_box
Beiträge: 15
Registriert: Mi 31. Aug 2011, 19:26

Re: [Bug] Auswahl der Hauptdatei

Beitragvon mind_in_a_box » Di 25. Okt 2011, 19:31

Normalerweise löst man sowas über SOAP, d.h. jeder Request an sich ist ein eigenes, valides XML-Dokument.

Normalerweise würde ich einfach den kompletten XML-String über TCP/IP schicken. Das reicht hier vollkommen aus.
Und ich denke nicht, dass du etwas anderes machst wenn du die Daten von deinem Client wieder zurück schickst?

Was spricht denn wirklich dagegen jede Aktion als kompletten String zu schicken? Das hat mit der Einfachheit des Loggens rein gar nichts zu tun. Ob du jetzt 200 oder 500 Zeichen in System.Out.print() steckst ist Java recht egal.
Dass etwas geloggt werden kann steht immer an letzter stelle, oder besser gesagt, es sollte das.

Warum man überhaupt unbedingt XML benutzt hat ist mir ein Rätsel, vermutlich weil Java das einem einfach macht und es heutzutage wohl überall benutzt wird. Einem C++ Programmierer macht man damit leider nur unnötig das leben schwer. Wir können halt nicht direkt XML in Klassen konvertieren. Nur über Umwege.
Und wenn, es gibt XML-Librarys. Ich habe kein Problem damit eine zu benutzen. Ich habe halt nur ein Problem damit, dass alles einfach Stückchenweise eintröpfelt.


Eine binäre Lösung hätte ich persönlich einfacher gefunden:

1. Byte: ID
2. Byte: Nummer der Info-Structs
3. - n. Byte: Info-Structs

Welches Struct man benutzen müsste, wüsste man durch die ID. Dadurch weiß man dann auch den Abstand der Structs im Byte-Array. Man müsste diese nur in seinen Code schreiben und passend befüllen:

Code: Alles auswählen

for(int i=2; i < sizeof(RoundInfo)*Data[1]; i+=sizeof(RoundInfo))
{
     RoundInfo Info;
     memcpy(&Info, &Data[i], sizeof(Info));

     Infos.push_back(Info);
}

Das dann noch für die verschiedenen Infos die man bekommen könnte eingebaut und fertig ist man. Und weniger Bandbreite braucht das auch noch! ;)

Naja, wie auch immer. Ich frage mich halt warum im Server nicht einfach soetwas gemacht wird:

Code: Alles auswählen

string xml = BuildXMLState(GameState);
SendDataToClients(xml);
System.Out.Println(xml);


Allerdings hatte ich mit Netzwerkprogrammierung noch nicht sehr viel am Hut, vielleicht gibt es ja sogar einen guten Grund dafür.
Was die Sicherheit wegen Buffer-Overflows angeht ließe sich auch eine Lösung finden, indem man die Größe des Packets mitschickt.

/rant ;)

ZeroByte
Beiträge: 25
Registriert: Mi 14. Sep 2011, 21:08

Re: [Bug] Auswahl der Hauptdatei

Beitragvon ZeroByte » Di 25. Okt 2011, 20:24

Normalerweise würde ich einfach den kompletten XML-String über TCP/IP schicken. Das reicht hier vollkommen aus.
Und ich denke nicht, dass du etwas anderes machst wenn du die Daten von deinem Client wieder zurück schickst?

Es ging mir eher ums Grundlegende - diese Art der Kommunikation ist vom Aspekt des Designs her nicht besonders wertvoll. (Es gibt auch Gründe, SOAP nicht einzusetzen. Es gibt tatsächlich Leute, die damit pixelweise Livestreams von ihrem Roboter an den Steuercomputer zur Weiterverarbeitung schicken und sich wundern, dass der gegen die Wand fährt :D )
Nichtsdestotrotz habe ich die Schnittstelle nicht entworfen und muss mich daran halten - kann also kein SOAP benutzen.

Was genau verstehst du unter einem "kompletten String"? XML-Dokumente sind auch nur Strings, somit schiebt SOAP auch nur Strings durch die Leitung ;)

Warum man überhaupt unbedingt XML benutzt hat ist mir ein Rätsel, vermutlich weil Java das einem einfach macht und es heutzutage wohl überall benutzt wird.

XML ist mit Abstand die schönste Lösung, die ich mir für sowas vorstellen kann. Hast du schonmal bitweise einen Stream zerlegt?

Ich habe halt nur ein Problem damit, dass alles einfach Stückchenweise eintröpfelt.

Das hat soweit nichts mit XML zu tun, sondern mit TCP/IP.

Eine binäre Lösung hätte ich persönlich einfacher gefunden

Für sowas nimmt man dann eher Protocol Buffers. Da hat man auch keine Probleme mit Buffer Overflows. Am schönsten ist aber noch, dass das Format trotz seiner binären Basis erweiterbar ist. Bandbreite auf localhost ist weniger ein Argument - auf meinem Rechner (Win XP) zb. läuft das nichtmal übern Netzwerk-Stack (und entzieht sich damit leider auch Wireshark :X) :D

Naja, wie auch immer. Ich frage mich halt warum im Server nicht einfach soetwas gemacht wird:

Wird das nicht so gemacht o.O ? Siehe das state-xml-tag?

MfG

mind_in_a_box
Beiträge: 15
Registriert: Mi 31. Aug 2011, 19:26

Re: [Bug] Auswahl der Hauptdatei

Beitragvon mind_in_a_box » Di 25. Okt 2011, 21:09

Nun, wie gesagt. Was Netzwerkprogrammierung angeht habe ich noch viel zu lernen. Habe mich die letzten Jahre eher mit Hardwarenaher Programmierung und GPUs geprügelt. ;)

Was genau verstehst du unter einem "kompletten String"? XML-Dokumente sind auch nur Strings, somit schiebt SOAP auch nur Strings durch die Leitung ;)


Gut, ich muss ehrlich gestehen, dass ich das zerstückelte XML für einen Bug oder eine Eigenart des Servers gehalten habe. Hatte eigentlich gedacht, dass man alle Daten die versendet wurden durch einen recv()-Aufruf bekommen könnte. Dem ist wohl wirklich leider nicht so.

XML ist mit Abstand die schönste Lösung, die ich mir für sowas vorstellen kann. Hast du schonmal bitweise einen Stream zerlegt?

Zitat des Dozenten eines Freundes: "XML ist häßlich, unnötig ausführlich und hat selten was mit logischem denken zu tun." :D

Zum Bitweise Streams zerlegen: Es ist sehr ineffizient solche Dinge wie Meshes oder Texturen als XML-Datei abzuspeichern. Also muss man sich seine eigenen Formate ausdenken.
Und diese natürlich auch wieder auslesen können. Da ich damit bis jetzt am meisten gearbeitet habe fällt es mir natürlich leichter und ich finde es komfortabler ;)

Für sowas nimmt man dann eher Protocol Buffers. Da hat man auch keine Probleme mit Buffer Overflows. Am schönsten ist aber noch, dass das Format trotz seiner binären Basis erweiterbar ist. Bandbreite auf localhost ist weniger ein Argument - auf meinem Rechner (Win XP) zb. läuft das nichtmal übern Netzwerk-Stack (und entzieht sich damit leider auch Wireshark :X) :D


Ja, Protocol Buffers scheinen wohl ziemlich genau das zu sein was ich meinte, nur halt einfacher umgesetzt, damit man sich nicht mit den einzelnen Bytes auseinandersetzen muss.
Das mit der Bandbreite war ein Scherz. ;)

Wird das nicht so gemacht o.O ? Siehe das state-xml-tag?


Jetzt wo ich verstanden habe warum der XML-Code nur häppchenweise ankommt klingt es auch logisch, dass es so gemacht wird.


Eine Lösung meines Problems habe ich so auch gefunden, Network-Streams:
http://www.flipcode.com/archives/Network_Stream.shtml

Werde mich morgen mal daran setzen die auszuprobieren, vielleicht kann dir das auch noch von nutzen sein.

npau
Beiträge: 9
Registriert: Di 9. Aug 2011, 10:49

Re: [Bug] Auswahl der Hauptdatei

Beitragvon npau » Mi 26. Okt 2011, 05:55

Hallo,
vielen Dank für die HInweise und die Diskussion!
Um die beiden Punkte 'Auswahl der Hauptdatei' und 'XML-Interpretation' wird sich demnächst gekümmert.