Netzwerkprotokoll mit Verschlüsselung, Kompression, Prioritätssystem und vielem mehr

[himitsu]

Zitat von MrMooed:

Kann das Projekt leider nicht öffnen mit meinem Delphi7 (klappt auch nicht wenn ich, wie du schoneinmal geschrieben hast, WinApi.Windows in Windows umändere. Dann meckert er, dass eine Vcl.Forms.dcu fehlt ..)

Dann entferne dort auch den Namespace

Mit XE2 wurden Namespaces für Units der RTL/VCL eingeführt.

System.SysUtils (System.SysUtils.pas bzw. System.SysUtils.dcu)
WinApi.Windows
WinApi.Messages
Vcl.Forms
Vcl.Dialogs
...

(in D2009 fing es mit den Units der Generics an, wo Punkte in Namen verwendet wurden)

[DataCool]

@Zacherl:
Ich habe es mir gerade aus Neugier grob angeschaut.
Deinen Ansatz/Aufbau finde ich gut, erstmal
Bei mir hat alles ohne jegliche Fehler geklappt.

Als Anregung würde ich Support von verschiedenen Socketkomponenten
vorschlagen, aber das steht glaube ich auch schon auf Deiner ToDo-List,
wenn ich mich recht an die Kommentare erinnere.

Greetz Data

P.S.: wenn Du noch mehr Funktionen mit Demo einbaust teste ich gerne

[Furtbichler]

Praktisch.

Eine Frage:

Ist "Intelligenter Datenempfang" eine Alternative zur "Trennung von Datenpaketen"? Kann ich auch intelligent senden, also nicht nur Dateien, sondern auch Daten?

[Zacherl]

Erstmal danke fürs testen euch beiden

Zitat von DataCool:

Als Anregung würde ich Support von verschiedenen Socketkomponenten
vorschlagen, aber das steht glaube ich auch schon auf Deiner ToDo-List,
wenn ich mich recht an die Kommentare erinnere.

Genau, das hatte ich schon geplant. Ich werde es wohl so handhaben, dass für den Sende Teil ein zusätzliches Event ausgelöst wird, in dem der User dann mit der Socket Komponente seiner Wahl die Daten abschickt. Der Empfangsteil sollte ja schon Socket unabhängig sein.

Zitat von Furtbichler:

Ist "Intelligenter Datenempfang" eine Alternative zur "Trennung von Datenpaketen"? Kann ich auch intelligent senden, also nicht nur Dateien, sondern auch Daten?

Definitiv. Wobei ich den "Intelligenter Datenempfang" logisch eher zu den "Einfachen Dateiübertragungen" zuordnen würde. Zur genaueren Erklärung: Wenn du "normale" Daten, also keine Dateien sendest, wird intern die TdxIDTPBaseTransfer Klasse erzeugt. Dort werden deine Daten in einen Buffer kopiert und dann nach und nach vom Sende Thread losgeschickt. Jetzt kann man sich vorstellen, was passiert, wenn man versuchen würde auf diese Weise beispielsweise einen Film (sagen wir mehrere Gigabyte) zu übertragen. Damit in diesem Falle nicht erst alle Daten in den Speicher geladen werden müssen, wird für Dateitransfers die TdxIDTPFileTransfer Klasse verwendet, welche die übergebene Datei öffnet und bei jedem Cycle des Sende Threads die Daten dynamisch per ReadFile() ausliest und abschickt.
Beim Empfänger kommt dann der "Intelligente Datenempfang" ins Spiel. Hat man einfache Daten, sagen wir mal einen Steuerbefehl mit ein paar Parametern, würde man diesen ja gerne "in einem Rutsch" empfangen, ohne ggfls. erst die Teilpakete wieder zusammensetzen zu müssen. Für diesen Zweck gibt es im OnTransferInit Event den variablen Parameter AutoCollectData. Ist diese Funktion aktiviert, sammelt der IOHandler alle eingehenden Daten eines Transfers in einen Buffer und löst das OnTransferFinish Event erst bei vollständigem Eingang aller Daten aus. Für große Dateien macht dies natürlich keinen Sinn, da man hier schnell wieder Speicherprobleme bekommen würde. Außerdem will man bei einem Dateitransfer die Datei in der Regel auch auf Empfängerseite wieder als solche speichern und nicht im RAM behalten. Hier kann man dann AutoCollectData deaktivieren, was bewirkt, dass bei jedem Teilpaket das OnTransferData Event aufgerufen wird. Das erlaubt es dann die Daten z.b. analog zum Sender per WriteFile() wieder in einer Datei abzulegen.

[gammatester]

Ist das nur ein Konzept oder soll das ernsthaft verwendet werden? Wenn ja, solltest Du in der Unit dxIDTPEncryptionProviderRCx nicht das Delphi-Random verwenden, was ja bekanntermaßen nicht besonders geeignet ist für Kryptoanwendungen. Außerdem wird es noch weiter verschlimmbessert durch Salt[I] := Random(255) , gemeint ist wohl Salt[I] := Random(256) .

Edit: Weiter ist mM ein Offset-Fehler mit Bufferoverflow-Potential vorhanden: In RCxEncode(FRCx, Salt[1], Output^, FSaltLength) muß die 1 doch wohl durch 0 oder Low(Salt) ersetzt werden.

Gruß Gammatester

[Zacherl]

Werde ich mir, wenn ich zu Hause bin nochmal anschauen. Kann sein, dass ich beim Salt vorher einen String verwendet habe und der Index 1 noch ein vergessenes Überbleibsel ist. Zur Random Funktion bzw. kryptographischer Sicherheit: Der RCx Provider dient als Beispiel. Du kannst dir gerne mit DEC einen AES Provider basteln, der auch die sicheren Random bzw. Salt Funktionen vom DEC verwendet. Primär geht es hier aber auch um das Protokoll und nicht um die verwendete Verschlüsselung oder Kompression.

[sh17]

Warum nicht die hier zum Verschlüsseln?

http://www.cityinthesky.co.uk/opensource/dcpcrypt

[Zacherl]

Leute ... :/ Ist zwar schön, dass ihr hier so toll auf die Verschlüsselung eingeht, aber hier geht es primär um das Protokoll. Die Verschlüsselung ist ein Feature das so umgesetzt ist, dass sich jeder User durch Ableiten vom entsprechenden Provider eine eigene Variante implementieren kann. Darin kann man dann jede erdenkliche Crypto Lib verwenden.

Bleibt bitte bisschen beim Thema. Der Hinweis von gammatester bezüglich des falschen Idizes ist definitiv wichtig, aber ich möchte hier keine Diskussion welche Crypto Lib am besten ist oder welcher Random Number Generator eine optimale kryptographische Sicherheit erzielt