Vielen Dank.
Auf den ersten Blick kann ich nichts erkennen, was prinzipiell falsch ist. Allerdings sind die zahlreichen Byte-Operation alle sehr fehlerempfindlich. Ich würde das grundsätzlich vermeiden und stattdessen einen sauberen OO-Weg gehen. Auch mein C++-Beispiel neulich ist nicht gut (hatte ich ja geschrieben).
Sauberer OO-Weg: Eine Klassenstruktur für die Telegramme entwerfen, mit einer abstrakten Basisklasse und einer konkreten Klasse für die unterschiedlichen Telegrammtypen. Die Klassen implementieren eine Schnittstelle zur Serialisierung/Deserialisierung. Zudem gibt es eine Factory, die beim Empfang anhand der ID ein Objekt einer konkreten Telegrammklasse erzeugt.
Jetzt der Socket-Empfang selbst. Zunächst grundsätzlich. Das Design sollte sich nicht von der Arbeitsweise des Sockets treiben lassen sondern umgekehrt von den Bedürfnissen der Anwendung. Die Anwendung will ganze Telegramme.
Alle Telegramme haben gemeinsam, dass sie aus einem festen Kopf und einem variablen Datenteil bestehen. Die Länge des variablen Teils ergibt sich aus den Informationen im Kopf.
Der Socket-Lesemechanismus sollte also mit zwei expliziten Lesezugriffen auskommen, einem für den Kopf, einem für den Datenteil. Socket-Kommunikation erwartet einen allgemeinen und nicht-typsicheren Byte-Puffer. Vom Puffer in Telegrammklasse und umgekehrt arbeitet aber der Serialisierer. Das beschränkt die fehlerträchtigen Bytes auf ein eng abgegrenztes Terrain.
Also:
Vom Socket Kopf als Bytes lesen in Puffer. Feste Länge. Deserialisieren im Kopf-Objekt. Das Kopf-Objekt liefert die ID. Mittels Factory nun das ganze Telegramm erzeugen, anhand der ID. Dem Konstruktor das Kopf-Objekt mitgeben.
Länge des variablen Datenteils steht im Kopfobjekt. Datenteil vom Socket in Puffer einlesen. Im vorher erzeugten Telegramm deserialsieren. Telegramm nach oben liefern.
Wie aber umgehen mit dem asynchronem Verhalten? Hier kann diese MFC-Klasse vielleicht tatsächlich helfen (ich würde es ohne MFC machen, heißt aber nicht, dass es nicht geht und in der MFC-Umgebung nicht zweckmäßig ist.) Die MFC-Klasse CSocket liefert ein Ereignis bei Datenempfang über Socket. Dieses Ereignis kommt mittels interner Mechanismen im Ereignisbehandlungsthread der MFC-Anwendung an. Das ist vom Grundsatz schon ein recht kompliziertes Muster mit der Kombination aus "Reactor" und "Active Object", aber durchaus handlich und sauber, so man denn MFC auch für diese Schicht verwenden möchte.
Das Ereignis bedeutet aber nur, dass Daten (oder eine Störungsmeldung) eingetroffen sind, gibt aber nicht die Datenmenge an. Die findet man durch den Lesezugriff heraus.
Es muss also eine eigene Socket-Nutzungsklasse geben, die dafür sorgt, dass immer vollständig gelesen wird. Diese eigene Socket-Klasse wird also sinnvollerweise das Ereignis registrieren. Jetzt hat man theoretisch zwei Möglichkeiten. Man verlässt sich auf das Ereignis, liest also immer nur genausoviel Daten, wie gerade da sind, und schreibt den aktuellen Zählerstand in eine Member-Variable. Dann wartet man auf das nächste Ereignis. Erst wenn alle Daten da sind, geht es mit dem Anwendungstelegramm weiter. Der andere Ansatz würde in der Ereignisbehandlungsfunktion solange erneut zu lesen versuchen, bis tatsächlich alle Daten da sind. Der Nachteil ist sofort zu erkennen. Die Ereignisbehandlungsfunktion kann blockieren. Das ist von Übel und scheidet daher für eine gute Praxis aus.
Vorher schrieb ich, dass es eine Ebene höher genau zwei Leseaufrufe geben soll, einen für den Kopf, einen für den Datenteil. Die Socket-Nutzungsklasse muss sich also nicht nur den aktuellen Zählerstand für die Bytes merken, sondern auch, in welchem der bedien Leseaufrufs sie steckt. Das ist etwas unschön an diesem Modell, das mit mit der MFC-Ereignisbehandlung arbeitet. Mein Ansatz wäre ein separater Thread (für C# neuelich so geschildert) und dann Methode #2 des vorigen Abschnitts. Nachteil: Man wird multi-threaded. Im Single-Thread-Ansatz wird der Lesevorgang also gegebenenfalls unterbrochen, wenn die Daten nicht vollständig sind. Man muss sich den aktuellen Zustand für einen späteren Wiedereinstieg vollständig merken, in Member-Variablen. (Das Modell dafür nennt man Co-Routine.)
Detail am Rande: Umkopieren von Bytes sollte man vermeiden. In C/C++ gibt man entsprechenden API-Funktionen immer denselben Puffer vor, ab dem zweiten Versuch dann mit einem Offset, der dem aktuellen Zählerstand entspricht.
Die Socket-Nutzungsklasse, von der hier die Rede ist, muss die konkreten Telegrammklassen gar nicht kennen. Es reicht vollkommen, wenn sie die Methoden einer abstrakten Basisklasse nutzen kann. Sie muss wissen, dass es einen Kopf und einen Datenteil gibt, sie muss die Längen für beide ermitteln können, und sie muss auf eien Factory zugreifen können, die die konkreten Telegramme erzeugt. Dies alles auf abstrakter Ebene (In Java oder C# würde man das per Interface regeln).
Man braucht demnach:
- Eine abstrakte Klasse, die serialize/deserialize-Methoden für einen Byte-Puffer ermöglicht
- Abstrakte Basisklasse für Kopf (darf pure virtual sein, quasi ein Interface). Muss ID und feste Länger ausgeben können. Muss die serialize/deserialize-Methoden unterstützen.
- Abstrakte Basisklasse für variablen Datenteil, wieder mit den serialize/deserialize-Methoden
- Abstrakte Factory, die Telegrammklassen erzeuegn kann. Hat eine create-Methode, die den abstrakten Kopf als Parameter nimmt und ein abstraktes Telegrammobjekt zurück liefert.
- Socket-Nutzungsklasse, die die zuvor genannten abstrakten Telegrammklassen nutzt. Diese Klasse wird das MFC-Ereignis "Daten vorhanden" abonnieren. Sie liest den Kopf, erzeugt per Factory das konkrete Telegramm (was sie nicht kennt) und liest den variablen Datenteil. Dies ggf in mehreren Anläufen. Erst wenn ein ganzes Telegramm vorliegt, geht das per Callback nach oben.
- Schließlich konkrete Klassen für den Kopf und jede Art von Telegramm, die vorkommen kann.
- Hierzu eine konkrete Factory.
Die Anwendung erzeugt ein Objekt der Socket-Nutzungsklasse, gibt sich selbst als Callback-Ziel für fertige Telegramme an, sorgt für genügend Info, dass die Socketklasse das "Daten vorhanden" Ereignis nutzen kann, und gibt der Socketklasse einen Telegrammkopf sowie die konkrete Factory mit.
Diese Lösung ist
- rein hierarchisch,
- kennt keine zirkularen Abhängigkeiten trotz scheinbarem gegenseitigem Bezug zwischen Telegramm- und Socketklasse,
- verteilt sauber die Aufgaben gemäß dem OO-Paradigma,
- ist wenig fehleranfällig, da extrem typsicher,
- lässt sich entsprechend einfach debuggen,
- und hat sich, in der Lösung mit separatem Thread, x-fach bewährt
... und nochmal 
), engl Pattern. Und nichts anderes geschieht bei meinem Ansatz.. Ich hätte auch ein UML-Diagramm zur Verdeutlichung zeichnen können. ![:]](./images/smilies/pleased.gif "Freude"){kind=small}
(UML in einfacher Form wird ja bereits an manchen Schulen gelehrt.)