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.