wobei das komplette Projekt noch lange nicht fertig ist, aber der Teil
ist fast fertig geworden.
Der Unterschied besteht nur, das ich die Daten über Pipes schicke
zwecks Kommunikation zwischen lokalen Programmen und nicht über
das Netzwerk, aber die zu übertragenden Daten können sich
jeder Zeit ändern, da wollt ich nicht das Protokoll ständig umbauen.
Also der ProtocolManager muss die entgültige Struktur nicht kennen,
der Aufbau wird ja als "Blueprint" eingelesen und genau anhand
dessen kannst du die Werte dann in den Speicher schreiben, so dass
dieser Speicher dann einer Struktur zugewiesen werden kann. Ob
der Programmierer nun alles richtig gemacht hat oder nicht ist ja dann
dir egal bzw. einfach davon ausgehen, dass es passt. Bei mir parsen
"Server" und "Client" eine XML-Datei (die selbe) und ermitteln so
den Aufbau der Datenpakete. Bisschen überdimensioniert, ich weis,
aber die XML-Datei enthält noch mehr Informationen darüber, die
hier jetzt nicht benötigt werden
Intern müssen die Programme mit den Daten ja arbeiten, daher erwarten
diese eine bestimmte "Struktur". Das heißt die Datenblöcke müssen
eine bestimmte Reihenfolge haben. Alles andere ist großer Overhead und da
das übermitteln der Daten im Hintergrund passieren soll, will ich das
vermeiden. So kann ich auf der Senderseite einfach den Zeiger auf die
Strukturvariable der Sendenfunktion und auf der Empfängerseite werden
die Daten direkt in einer Strukturvariable geliefert. Das ganze arbeitet
natürlich heftigst mit Zeigern und beschreibt bzw. ließt Speicher "zu Fuß",
aber um so kniffliger die Aufgabe um so erfreulicher wenns klappt, oder?
Da nicht jedes Programm alle Daten braucht, muss für jedes Datenfeld
ein Flag gesetzt werden. Nur wo das entsprechende Flag gesetzt ist,
wird das Datenfelder dann auch übertragen. Es werden also erst mal
die Flags gesendet und anhand dessen dann das tatsächliche Datenpacket
geschnürrt oder ausgelesen. So übertrage ich auch Listen in Listen.
Tatsächlich ist aber trotzdem nur jeweils ein "Send" und "Receive" Befehl
nötig, egal wie komplex das Protokoll ist. Die ganzen "Add_EntryXXX"
und "R_GetXXX" sind ja nicht überflüssig, sie machen das ganze noch
dymaischer für Fälle, wo es tatsächlich machbar ist, aber ich persönlich
find's für die meisten Fälle zu umständlich, weil wie schon gesagt das
Programm so wie so eine genaue Struktur kennen muss, um mit den
Daten überhaupt arbeiten zu können. Bringt ja nichts, wenn z.B. die
Positionsdaten mal in Byte 10 stehen und mal in Byte 5. Der Client
braucht die Daten so oder so im Speicher der Variable "Position"
und wo die liegt ist fest im Programm verankert. Und wenn nun
plötzlich die Logik so verändert wird, das diese Daten garnicht mehr
benötigt werden, muss die Logik des Clients so wie so geändert werden.
Dabei kann dann die zu erwartende Struktur auch angepasst werden.
Das ist ja kein wirklicher Aufwand. Aufwändiger ist es, die ganzen
Add und Get aufrufe neu schreiben zu müssen.
MFG PMV
). Dafür steht die Hilfsfunktion ENM_Auth_HashPassword() zur Verfügung. Eine meiner Lieblingsfunktionen ist die ENMAS\Panic() Funktion. Wurde diese Funktion aufgerufen werden alle Sessions ungültig, kein weiterer Login ist möglich. Keine Funktion geht mehr außer Free() und Export(), einfach eine Sicherheitsfunktion falls ein Sicherheitsverstoß festgestellt werden sollte.
