AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Projekte Netzwerkprotokoll mit Verschlüsselung, Kompression, Prioritätssystem und vielem mehr

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

Ein Thema von Zacherl · begonnen am 24. Sep 2012 · letzter Beitrag vom 16. Okt 2012
Antwort Antwort
Seite 2 von 2     12
Benutzerbild von Zacherl
Zacherl
Registriert seit: 3. Sep 2004
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:
  • Die ZLibEx Unit für den TdxIDTPCompressionProviderZLib gibt es hier:

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
Angehängte Dateien
Dateityp: rar IDTP.rar (11,1 KB, 53x aufgerufen)
Dateityp: rar IDTPDemo.rar (115,1 KB, 60x aufgerufen)
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)

Geändert von Zacherl (10. Okt 2012 um 14:30 Uhr)
 
gammatester
 
#11
  Alt 16. Okt 2012, 10:58
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

Geändert von gammatester (16. Okt 2012 um 11:14 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

 
Delphi 10.2 Tokyo Starter
 
#12
  Alt 16. Okt 2012, 11:49
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.
  Mit Zitat antworten Zitat
Benutzerbild von sh17
sh17

 
Delphi 10.3 Rio
 
#13
  Alt 16. Okt 2012, 13:20
Warum nicht die hier zum Verschlüsseln?

http://www.cityinthesky.co.uk/opensource/dcpcrypt
Sven
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

 
Delphi 10.2 Tokyo Starter
 
#14
  Alt 16. Okt 2012, 14:12
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
  Mit Zitat antworten Zitat
Benutzerbild von sh17
sh17

 
Delphi 10.3 Rio
 
#15
  Alt 16. Okt 2012, 15:02
So war es auch nicht gemeint, sollte nur unterstreichen, das es eben funktionierende Klassen gibt, eben weil es hier um das Protokoll geht. Sieh es als Ergänzung/Empfehlung/Beigabe.
Sven
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

 
Delphi 10.2 Tokyo Starter
 
#16
  Alt 16. Okt 2012, 15:50
So war es auch nicht gemeint, sollte nur unterstreichen, das es eben funktionierende Klassen gibt, eben weil es hier um das Protokoll geht. Sieh es als Ergänzung/Empfehlung/Beigabe.
Alles klar kein Ding Hatte ja vorher auch schon das DEC als Alternative Crypto Klassen Sammlung angemerkt.

@gammatester:
Du hattest recht, der Index 1 und die 255 im Random sind falsch. Werde ich korrigieren und beim nächsten Update integrieren.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:23 Uhr.
Powered by vBulletin® Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf