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

[Zacherl]

Hallo zusammen,

in diesem Thread habe ich ein paar Anregungen für ein Netzwerkprotokoll gesucht. In der Hoffnung, dass mir ein paar Leute beim Testen helfen und vielleicht noch einige Verbesserungsvorschläge auftauchen, präsentiere ich hier schonmal den aktuellen (voll funktionsfähigen) Fortschritt.

Die wichtigsten Features im Überblick:

• Trennung von Datenpaketen
  • Jedes Paket kommt unverändert und korrekt getrennt beim Empfänger an.
  • Zwei schnell aufeinander gefolgte Datenpakete kommen so beispielsweise nicht in einem Rutsch an, wie es normalerweise bei TCP die Regel ist.
• Simultane Übertragungen
  • Durch dieses Feature ist es möglich, mehrere Übertragungen gleichzeitig über eine einzelne Verbindung ablaufen zu lassen.
  • Die maximale Anzahl an gleichzeitigen Übertragungen kann individuell festgelegt werden.
• Einfaches Prioritätssystem
  • Priorisierte Übertragungen sind auch dann aktiv, wenn die maximale Anzahl an gleichzeitigen Übertragungen bereits erreicht ist. So kann man beispielsweise Steuerbefehlen einen Vorrang vor Dateitransfers einräumen.
• Transparente Verschlüsselung
  • Über einfache Encryption Provider Klassen können sämtliche Benutzerdaten vollständig transparent verschlüsselt übertragen werden.
• Transparente Kompression
  • Analog zur Verschlüsselung können die Benutzerdaten automatisch blockweise komprimiert werden.
• Transferkontrolle
  • Sowohl Sender als auch Empfänger kann über einfache Methoden eine Übertragung pausieren, fortsetzen oder abbrechen.
• Eventbasierte Funktionalität
  • Verschiedene Events, wie beispielsweise OnTransferInit, OnTransferWork, OnTransferData und OnTransferFinish bieten dem Entwickler eine komfortable Schnittstelle.
• Einfache Dateiübertragungen
  • Integrierte Unterstützung für Dateiübertragungen. Hierdurch müssen Dateien nicht erst vollständig in den Speicher geladen werden, um sie verschicken zu können.
• Intelligenter Datenempfang
  • Der Empfänger kann pro Übertragung seperat entscheiden, ob er über die eingehenden Daten bei jedem Block, oder erst am Ende der Übertragung informiert werden will.
  • Erstere Möglichkeit bietet sich beispielsweise für Dateiübertragungen an. Bei der zweiten Variante sorgt IDTP automatisch für das Sammeln der Daten im Speicher.
• Meta Informationen
  • Jeder Übertragung können Meta Daten hinzugefügt werden, welche dem Empfänger (und Sender) sofort beim Start des Transfers in den Events zur Verfügung stehen. Diese Daten werden auch dann sofort gesendet, wenn die eigentlichen Benutzerdaten z.b. aufgrund der maximalen Anzahl an gleichzeitigen Übertragungen noch nicht gesendet werden.

Weitere Informationen:

• Hagen Reddmanns RCx Unit, welche im TdxIDTPEncryptionProviderRCx verwendet wird, findet ihr hier:
  • RCx-Verschlüsselung
• Die ZLibEx Unit für den TdxIDTPCompressionProviderZLib gibt es hier:
  • ZLibEx für Delphi

Eine (einfache) Demo Anwendung habe ich als Anhang hinzugefügt. Ich würde mich über jeden Test und vor allem auch über Verbesserungsvorschläge sehr freuen

Viele Grüße
Zacherl

[ByTheTime]

Uff... ich schau mir das gearde an. Hast du auch dazu eine Demo Dann würde ich mir erstmal schneller einen Überblick schaffen können. Eventuell würde ich sie dann in mein bestehendes Protkoll einbinden, ich war die ganze Zeit auf der Suche nach soetwas, denn im Moment kommt in meinem Projekt der Punkt, wo es um das übertragen von Dateien geht, und da wird es schon ziemlich schwierig selbst was auf die Beine zu stellen. Ein ordentliches Protkoll kommt mir da sehr recht Und ich arbeite auch gearde mit der Verschlüsselung... Da läuft im Moment auch nicht alles rund :S

[Zacherl]

Hatte im Moment leider noch ein paar andere Sachen zu tun, deshalb ist die Entwicklung der Demo etwas eingeschlafen. Werde die Tage mal dran weiterarbeiten, bzw. kann dir gerne die unfertige Demo schonmal vorweg per PM schicken, wenn du magst. Ist soweit eigentlich alles drinnen, was man braucht, um sich einzuarbeiten.

[Zacherl]

Hier mal ein kleines Update:

• Jeder Transfer hat nun eine eigene Instanz des Encryption- und Compression Providers
• Der MetaData Provider wurde entfernt
• Neue Helfer Klassen für einfaches Senden und Empfangen von Daten- oder MetaDaten Paketen wurden hinzugefügt
• Verschiedene Bugfixes

Die meisten Anregungen aus dem Konzept Thread habe ich aus Zeitgründen noch nicht eingebaut, allerdings habe ich jetzt mal eine kleine Demo Anwendung hinzugefügt.

[MrMooed]

Bin auch gerade auf der Suche nach einer Möglichkeit Daten zu übermitteln - wobei dein Projekt für mich wohl ein Paar Größenordnungen zu überdimensioniert ist

Könntest du evtl. eine .Exe hochladen ? 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 ..)

Klingt auf jedenfall vielversprechend

[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.