AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Netzwerke Delphi Konzept: Netzwerkprotokoll
Thema durchsuchen
Ansicht
Themen-Optionen

Konzept: Netzwerkprotokoll

Offene Frage von "BUG"
Ein Thema von Zacherl · begonnen am 18. Sep 2012 · letzter Beitrag vom 25. Sep 2012
 
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.629 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#3

AW: Konzept: Netzwerkprotokoll

  Alt 18. Sep 2012, 20:26
Hallo BUG, danke für deine Antwort.

Vielleicht sollte man das über die Thread-Priorität regeln.
Gute Idee

Brauchst du wirklich mehr als 2^16 Verbindungen? Schon eine 2^16 Lookup-Table ist imho ziemlich groß.
Ich bezweifele es, würde aber trotzdem lieber auf Nummer sicher gehen.

Dann würde ich vorschlagen, dass der Empfänger das erste Paket bestätigen muss ... damit gibt er bekannt, das er genug Ressourcen (und Fähigkeiten*) für diese Verbindung hat und das der Schlüssel richtig ist. Im ersten Paket gibt es bei verschlüsselten Verbindungen eine verschlüsselte Zufallszahl (Challenge), die der Empfänger entschlüsselt** wieder zurücksenden muss. Wichtig wäre dabei: Priorisierte Nachrichten sollten immer eine vorbereitete Verbindung haben.
Im Prinzip auch eine Gute Idee. Vorbereitete Verbindungen sind immer schwierig, da ich mir nie sicher sein kann wie viele priorisierte Nachrichten unter Umständen gleichzeitig geschickt werden. Das Challenge und Capabilities Ping Pong Prinzip werde ich wohl als extra Funktion einbauen, um die Verschlüsselung und Kompression abzusichern. Allerdings werde ich es hier so handhaben, dass entweder der Client oder Server (je nachdem wer das erste Paket sendet) hier manuell tätig werden muss. In einem Event signalisiere ich dann auf beiden Seiten, dass die Verbindung abgesichert ist. Danach erst können "normale" Pakete gesendet werden.

Wenn du die Zuordnungstabelle auf Empfängerseite besser verwalten willst, dann lass den Sender eine eigene Nummer zurücksenden, die der Sender ab jetzt benutzen soll. Der Empfänger meldet sich weiter mit der ursprünglichen ID an den Sender.
Kannst du eventuell eine Vermutung bezüglich der Performance antizipieren? Das Protokoll soll unter anderem in einem Reverse SOCKS5 Proxy zum Einsatz kommen. Bei meinem ersten Versuch habe ich pro Verbindung ein neues Socket erstellt, dann die Challenge ausgetauscht und dann mit der Datenübertragung begonnen. Das war enorm langsam. Bin mir aber nicht sicher, ob es an den immer neuen Sockets (ohne Thread Pool etc) lag oder am Key Exchange.

Wenn der Sender oder Empfänger eine Verbindung (Chancel) abbrechen wollen, schicken sie ein Paket, das auch den Grund nennt (User/Fehler/...). Das kann er auch senden, wenn er die Verbindung nicht haben will.
Klingt nett. Bisher habe ich ein Flag für Suspend, Resume und Cancel vorgesehen. Dort könnte ich im Datenteil des Pakets mit Leichtigkeit noch eine Fehler ID übertragen.
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)
  Mit Zitat antworten Zitat
 


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 09:08 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz