Mein Prinzip der AES256bit Cryptography ist die Teilung von Schlüsselmanagement im Core und dem Codieralgorythmus beim jeweiligem Prozess. Die Schlüssel können von Core zu Core übertragen werden. Dies stellt dann auch die Datensicherung da, die ansonsten nicht weiter vorgesehen ist.

Der Core verfügt über eine eigene Databaseseengine. Diese hat ein Wartungsmodul mit zwei Aufgaben. Den "Perfekten Ausgleich"(PA) der Binare-Search-Tree(BST) und die Startoptimierung(SO) der Datenbankdateien. Letzteres ist vergleichbar mit dem Defragmentieren von Datenträger. Die SO dient nur der Beschleunigung des Startes der DB-Engine durch eine für den Start optimierte Anordnung der Daten in den DB-Dateien. Die SO selbst kann abhängig von Größe und Fragmentierung der DB-Dateien einige Minuten in Anspruch nehmen. Es empfiehlt sich den Vorgang manuell durchzuführen. Der PA der BSTs geht sehr schnell, da die BSTs sich im Cache der DB-Engine befinden und dabei nur "Zeiger umgehangen" und keine Daten verschoben werden. Der PA wird auch bei jedem Start des Cores ausgeführt. Diese beiden Aufgaben können auch automatisch zu einer vorgegeben Zeit ausgeführt werden, wenn beispielsweise der Core im 24/7 Betrieb läuft.

Über den Port 5111 kommunizieren die Cores untereinander. Der Verbindungsaufbau zu IPV6-Adressen wird bevorzugt hergestellt und ist mindestens 10 sek. schneller pro Verbindung. Die Standard Waittime zwischen Core zu Core Verbindungen beträgt 10 sek. und zwischen Prozess zu Core 10 sek. bevor der Vorgang abgebrochen wird.

Zur Installation des Cores startet man die Eingabeaufforderung (DOS-Prompt) als Administrator. Wechselt in das Verzeichnis in der sich die Datei Core.exe befindet und gibt core -install ein. Weitere Optionen können durch Eingabe von core -h angezeigt werden. Alternativ kann man komfortabel über den Windows-Installer durch Verwendung der RePagCore64.msi Datei eine komplette Installation durchführen. Die Windows-Installer Variante ist auch die empfohlene Variante.

Das Abstract-Data-Types Project ist ein Open-Source-Project. Bei den Funktionen FLOATzuCHAR() und DOUBLEzuCHAR() wird nur in der Darstellung gerundet. Der interne Wert bleibt unverändert. Bei Angabe von 8-Stellen bei FLOATzuCHAR() und bei der Angabe von 16-Stellen bei DOUBLEzuCHAR() wird nicht gerundet. Stattdessen wird der echte Wert dargestellt mit dem der Prozessor in Wahrheit intern rechnet. Für eine 100% Genauigkeit, wie sie beispielsweise in der Finanzwirtschaft gefordert wird, empfehle ich die Verwendung von COComma4 und COComma4_80. Bei diesen beiden Datentypen wird nach kaufmännischen Runden entsprechend der DIN-Norm 1333 gerundet.

Zusätzlich wir noch die Datei FileVers.dll auf der Prozess-Seite benötigt. Die einzige Aufgabe dieser Datei besteht darin, die jeweilige Dateiversion aller im Programm verwendeten RePag-DLL-Dateien zur Programmversion zusammen zu halten. Es ist daher später nicht möglich beim User eine RePag-DLL-Datei mit dem gleichen Dateinamen einer anderen Dateiversion zu tauschen. Ein offizielles Update ist weiterhin möglich.

Aufgrund der umfangreichen Änderungen am Cryptho-Algorithmus ist der Core ab Version 2.0.4.1 im Bereich der Datenbankdateien und des Protokolls nicht abwärtskompatibel. Die Portnummer wurde von 5111 auf 5115 verlegt.

Hinweis: Jeder Core verfügt über sein eigenen Datenbankschlüssel, daher ist das kopieren von Datenbankdateien nicht möglich. Jede Core zu Core Verbindung verfügt über ihren eigenen Schlüssel, der periodisch nach einer Zeit oder/und nach Anzahl von Benutzungen getauscht wird. Der Core ist ein Viertel vom Ganzen einer Client/Server Architektur, in dessen Verbund seine Aufgabe darin besteht, die anfallenden Daten zu verschlüsseln. Jeder Core versucht sich periodisch mit den Core unter core.repag.net zu verbinden. Sollte ich den schalten, würden sich alle Cores die über das Internet erreichbar sind, miteinander verbinden und Schlüssel tauschen. Mehr nicht!