Das deutsche Python-Forum

Moin zusammen,

das Projekt mcipc ist schon etwas älter und wir auch bereits von Dritten benutzt.
Es ist eine Client Bibliothek, welche mittels der Query und RCON Protolle mit Minecraft Servern kommunizieren kann.
Dies dient zum Abfragen von Serverinformationen (Query) sowie dem Ausführen von Kommandos auf dem Server (RCON).
Ich habe letztes Wochenende die Version 2.0 veröffentlicht, welche für alle offiziellen Minecraft Flavors entsprechende Clients mit den Methoden der passenden RCON Befehle zur Verfügung stellt.
Ebenfalls, habe ich den generischen RCON Client abgetrennt.
Wenn ihr selbst Minecraft Server hostet, und diese aus Python Programmen heraus steuern wollt, könnte mcipc für euch interessant sein.

Ein Blick reicht um zu sehen, dass die Socketkommunikation fehlerhaft ist. Für ein Paket, das genau dafür da ist, ein schwerer Fehler. Man kann sich das Leben schwer machen oder einfach socket.makefile benutzen.

Kannst du das bitte konkretisieren? Was genau ist fehlerhaft?

Zumindest im Client ist mir aufgefallen, dass der Generator abbricht, wenn ein chunk kleiner als die buffer-size ist. recv kann aber auch weniger Bytes liefern, als die angegebene buffer-size, selbst dann, wenn noch mehr Daten vom Server folgen. Die buffer-size ist der Maximalwert und nicht garantiert.

makefile, wie von Sirius3 erwähnt, kann diese Schwierigkeit umgehen, dafür aber Probleme bereiten, wenn zusätzlich ein timeout verwendet wird.

Das Problem ist, dass das Query Protokoll keinerlei Informationen beim Abfragen liefert, wie lang die Serverantwort ist.
Wenn ich einfach ein makefile verwende und damit vom Socket lese, hängt sich die Methode dort auf, da auf mehr Daten gewartet wird, welche nicht kommen.
Wenn ihr eine Möglichkeit seht, die Methode wissen zu lassen, dass die Übertragung vom Server abgeschlossen ist, lasst es mich bitte wissen.
Natürlich will ich meinen Code wenn immer möglich verbessern.

Das spezielle Protokoll kenne ich nicht, wenn aber keine Längeninformation mitgeliefert wird, sollte stattdessen eine Terminierungssequenz definiert sein. So lässt sich feststellen, ob der Empfang vollständig war (oder "übervollständig", falls der Server pushed). Bei textbasierten Protokollen ist das oft der Newline-Character.

Ich habe es jetzt mal refactored und Abbruchbedingungen für die einzelnen Responses hinzugefügt.
Das war relativ tricky, aber läuft nach ersten Tests stabil.