Bitte um Hilfe beim Debuggen der SVDRP peer-to-peer Kommunikation

kls · 5. Februar 2018

Ich versuche seit Tagen, einen Fehler bei der peer-to-peer Kommunikation zwischen VDRs zu finden, komme aber irgendwie nicht weiter. Daher wollte ich mal hier fragen, ob da jemand mit draufschauen mag.

Der Fehler tritt (zumindest hier bei mir) bei folgener Vorgehensweise auf:

- Zwei VDRs mit Version 2.3.8 im selben Netzwerk, gegenseitig über SVDRP erreichbar und mit aktiviertem Peering.

- Der eine VDR sei "Remote", der andere "Local", alle Benutzerinteraktion erfolgt auf dem VDR "Local".

- Auf dem Remote-VDR befinden sich etliche Timer.

- Auf dem Local-VDR das Timers-Menü öffnen und bei einem beliebigen Timer (egal ob local oder remote) die Rote Taste drücken, um den Timer ein- bzw. auszuschalten. Dabei ist es egal, ob es ein einmaliger oder ein wiederholender Timer ist.

- Macht man das mehrmals hintereinander mit genügend zeitlichem Abstand, so dass die Kommunikation vollständig ablaufen kann, dann funktioniert alles wunderbar.

- Drückt man die rote Taste aber schnell hintereinander mehrfach, so kommt es irgendwann zu Fehlermeldungen.

Ich konnte es bisher soweit eingrenzen, daß im Fehlerfall in cSVDRPClient::Process() der Aufruf von file.Ready(false) 'false' liefert, obwohl eigentlich eine Antwort des Remote-VDR anstehen sollte. Bei meinen Untersuchungen habe ich die im beiliegenden Patch zu sehenden Änderungen gemacht, um dafür zu sorgen, dass auch dann, wenn keine Response benötigt wird, eine eventuell schon angefangene Antwort auch fertig gelesen wird. Leider hat das das eigentliche Problem aber nicht behoben.

Vielleicht fällt einem von euch ja was auf, woran das liegen könnte.

Klaus

TomJoad · 9. Februar 2018

Ich konnte das nachstellen, weiss aber nicht ob es das einzige Szenario ist:

Der Client setzt schnell hintereinander MODT Kommandos ab

Es kann passieren, dass nachdem das Kommando am Server angekommen ist, aber bevor sich die CmdLSTT den WRITE_LOCK holt,

die Mainloop am Server ein LSTT ID zum Client schickt. Dieses Kommando bleibt beim Client hängen (weil dort das Modifizieren des Timers den Lock schon hat.

Am Server bleibt CmdLSTT hängen weil in der main Loop vor dem GetRemoteTimers und LSTT ein Lock geholt wird.

!! Also ein systemübergreifender Deadlock, der aber durch die Timeouts wieder aufgelöst wird !!

kls · 15. Februar 2018

Ich glaube den Fehler gefunden zu haben.

In cSVDRPServer::Reply() wurde der Antwort-String in drei Teilen geschickt. Zuerst der Code, dann der Text und schließlich das '\r\n'. Beim Debuggen habe ich immer wieder gesehen, dass die Antwort auf den POLL-Befehl in zwei Teilen bearbeitet wurde, zuerst "250 " und dann "OK\r\n". Anscheinend ist da irgendwie ein Interrupt dazwischengekommen.

Mit der beiliegenden Änderung konnte ich den Fehler bisher nicht mehr reproduzieren.

Die Zeilennummern können evtl. etwas "off" sein, da ich inzwischen auch schon andere Änderungen vorgenommen habe. Der Diff sollte aber auf jeden Fall anwendbar sein.

Klaus

Jetzt mitmachen!

Teilen