Das Core-Programm ist ein proprietäres Project. Es stellt ein Prozessmanagement für bis zu achtzehn Prozesse
zur Verfügung. Um die Geschlossenheit und Unabhängigkeit zu gewährleisten benötigt der Core keine weiteren Dateien.
Die ComSys.dll ist das kommunizierende Gegenstück auf der Seite des jeweiligen Prozesses. Diese Datei
benötigt noch einige Teile aus der ADT.DLL. Somit werden diese beiden Dateien auf der Seite des
jeweiligen Prozesses benötigt. Beim Start eines Prozesses wird automatisch eine Verbindung zum Core hergestellt.
Für alle verbundenen Prozesse besteht die Möglichkeit mit der Klasse COVMBlockShared gemeinsam auf den
gleichen Memorybereich zuzugreifen. Des weiteren hat der Core sein eigenes Memorymanagement sowie sein
eigenen Certificatestore und ein Keymanagement für AES256bit-Schlüssel. Der Quellcode des Programms
Core.exe und die Library CompSys.dll werden aus Sicherheitsgründen nur zum Teil veröffentlicht. So zum Beispiel
das Memorymanagement
und die Cryptography.
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 RePagCore32.msi
oder 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.
Zur Verbesserung der Sicherheit wurde noch einmal eine Änderung am Protokoll vorgenommen, die dazu führt, dass der
Core ab Version 2.0.4.6 nicht abwärtskompatibel ist. Der Cryptho-Algorithmus und die Datenbankdateien bleiben unverändert.
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!
File: Core.exe - Prozess Management / Version: 2.0.4.6 - Last Update: 01.12.2024
Package: RePag.Core / Version 2.4.6 - Last Update: 01.12.2024
Install: Core / Version 2.4.6 - Last Update: 01.12.2024
File: FileVers.dll - Dateiversion Management / Version: 3.1.5.7 - Last Update: 01.12.2024
Package: RePag.FileVersion / Version 3.15.7 - Last Update: 01.12.2024
File: CompSys.dll - CPU und OS Funktionen / Version: 2.2.6.6 - Last Update: 15.09.2024
Package: RePag.System / Version 2.27.6 - Last Update: 15.09.2024
File: ADT.dll - Abstrakte Datentypen / Version: 2.3.7.5 - Last Update: 15.09.2024
Package: RePag.System / Version 2.27.6 - Last Update: 15.09.2024