Hallo Sebastian,

ich habe gerade fast drei Stunden mit Leon und einem seiner Kollegen zusammengesessen und sie haben mir noch genauer über ihre Probleme beim Robocup erzählt.

Immerhin weiß ich jetzt, wie ihr Setup aussah: sie hatten auf ihrem großen, mobilen Roboter einen rsb-loggercpp als Socket Server, mit dem sich alle Komponenten auf der gleichen Maschine verbunden haben. Das exotischere ist, dass sich über WLAN-Verbindungen noch mobile Roboter mit diesem rsb-loggercpp verbunden haben.

Der Fehler vom Wochenende entstand offenbar dadurch, dass aufgrund der schlechten WLAN-Verbindung Daten unvollständig übertragen und TCP-Verbindungen abgebrochen wurden. An sich ist das noch kein Problem, aber scheinbar stürzt die C++-Implementierung bei solchen Verbindungsabbrüchen unter gewissen Umständen beim Schreiben einer Log-Ausgabe ab. Ich arbeite noch daran, das zu reproduzieren.

Die Einschränkung, dass Protocol Buffer Messages von mehr als 64 MB von der C++ Implementierung als Vorgabe nicht verarbeitet werden (und der scheinbare Implementierungsfehler in dieser Einschränkung), existiert weiterhin, war aber, wie vermutet, nicht der Grund für den obigen Fehler. Hierüber sollten wir uns separat nochmal Gedanken machen.

Zusätzlich zur Diskussion dieses speziellen Fehlers, wurden auch diverse Wünsche geäußert:

    Eine Server/Bridge Komponente für RSB, die nur diese Aufgabe erfüllt und sonst nichts tut, um die Gefahr eine Absturzes zu minimieren. Der Eindruck ist offenbar, dass der Logger als Server zu viele unnötige Dinge macht, und damit das Risiko eines Absturzes erhöht. Die Frage nach der Bridge-Funktionalität ergab sich aus dem Wusch, ein RSB-System mit einem Spread-basierten und einem Socket-basierten Teil zu bauen.
    Für den Socket-Transport sollten Client-Teilnehmer im Fall eines Verbindungsabbruchs die Option haben, automatisch einen erneuten Verbindungsaufbau zu versuchen. Die Motivation hier sind mobile Roboter im WLAN-Netz, die manchmal ihre TCP-Verbindungen verlieren.
    Der Socket-Transport soll intelligent Subscriptions verwalten, so dass Daten nur zu den (TCP) Endpunkten übertragen werden, die sie auch wirklich brauchen. Die Motivation sind wieder per WLAN verbundene mobile Roboter, die weder netzwerk- noch rechenleistungsmäßig mit dem zwangsweisen Empfangen des gesamten Datenverkehrs des System klarkommen.
    Der "auto" Modus des Socket-Transport war in diesem Fall aufgrund des "intelligenten" aber nicht gut vorhersagbaren Verhaltens eine Fehlerquelle bzw. ein Hindernis bei der Fehlersuche.

1, 2 und 3 sind vermutlich für uns relevant, weil sich offenbar (nach Aussage von Leon und seinem Kollegen) Stefan Herbrechtsmeier und seine Kollegen für ihre Setups mit mehreren kleinen, mobilen Robotern schon mehr oder weniger endgültig auf die Verwendung des Socket-Transports festgelegt haben. Das scheint auch daran zu liegen, dass sie für die dort eingesetzten ARM-Architekturen Spread nicht bauen oder verwenden können. Der gewünschte Zeitrahmen scheint hier einige Wochen bis zwei Monate zu betragen :)

Als letzte Anmerkung: Die Fehlersuche im Robocupkontext wurde durch ein chaotisches Deployment mit einer Mischung der "0.8", 0.9 und 0.10 Versionen und obskurer Compiler-Einstellungen aus dem GAR-Installer erschwert.

@Johannes: ein weiterer, damit zusammenhängender Punkt war noch unsere Empfehlung in rsb-cpp/INSTALL, mit CMAKE_BUILD_TYPE=debug zu bauen, weil dann der GAR-Installer mit -O3 oder noch aggressiveren Optmierungseinstellungen alles wieder zunichte machen kann (die gleiche Empfehlung steht auch in build-system-essentials für C++). Empfiehlst du nicht sonst immer RelWithDebugInfo?

Viele Grüße,
Jan