spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »birdfreeyahoo«

Und der aber als extra Thread, weil sonst nicht mehr empfangen wird, solange der zum Beispiel in den Datenbanken herumschreibt/liest?
Oder ist das egal, weil es ein Stream-Socket ist und ich nacher alles auslesen kann was dazwischen angekommen ist?

Das Auslesen kannst du eine gewisse Zeit unterbrechen, bis der Empfangspuffer voll ist oder ein Timeout erreicht wird. Du willst aber währenddessen üblicherweise auch noch weiter Verbindungen annehmen.

Eine Möglichkeit wäre für alles Threads zu erzeugen. Also ein Thread der Verbindungen annimmt und dann jede Verbindung einem eigenen Thread (aus einem Threadpool, da neu erzeugen meist aufwändig ist) übergibt. Da musst du natürlich alle Stellen wo Daten zwischen den Threads übertragen werden absichern.

Alternativ lässt sich das auch asynchron lösen. Bedingung dafür ist, dass keine blockierende Aktionen durchgeführt werden, die länger brauchen. Dann kannst du einfach durch ankommende und aktive Verbindungen iterieren und diejenigen verarbeiten die es gerade nötig haben. Man spart sich dabei die Synchronisierung der Threads. Wird gerne im Web Bereich verwendet um sehr viele Verbindungen zu verarbeiten. Für einen einfachen Loginserver wäre das vielleicht auch eine Option.

Zitat von »birdfreeyahoo«

Ok danke. Noch eine Frage hätte ich: Ich will die Daten mit AES verschlüsseln, dafür brauche ich einen Initialisierungsvektor und einen Key. Zufall ist nicht, da der Server wieder entschlüsseln muss, was nimmt man dann, nimmt man x-beliebige, konstante keys, oder sendet man ihn mit RSA verschlüsselt mit?

Was du suchst ist https://en.wikipedia.org/wiki/Password-a…d_key_agreement wie z.B. https://en.wikipedia.org/wiki/Secure_Rem…ssword_protocol was unter anderem von Blizzard für alle aktuellen Spiele verwendet wird.

Einen Schlüssel einfach mitschicken reicht nicht, da sich ein Angreifer mit dessen Wissen einfach das Passwort rausholen könnte. Feste Keys geht nicht, da ein Angreifer einfach die gesendeten Daten abfangen und von sich aus schicken könnte. Da muss schon etwas mehr Aufwand betrieben werden um sicherzugehen das Client und Server die gleichen Benutzerdaten kennen.

Wieso glaubst Du, dass das auch nur Ansatzweise sicher wäre?

Nächste häretische Frage: willst du etwas lernen oder willst du eine funktionierende Lösung?
Im ersten Falle kannst du ruhig den angefangenen Weg weitergehen. Anderenfalls rate ich zur Nutzung fertiger Bibliotheken. Dann kannst du dich nämlich auf dein eigentliches Ziel konzentieren und musst nicht voraussichtlich 1-2 Jahre für Netzwerkgeschichten investieren.
Nebenbei erwähnt reicht ein Netzwerkthread in Verbindung mit einem select um den listen und alle client sockets zu überprüfen völlig. Von "1 client:1 thread" kann ich nur abraten, da threads bzw viele threadwechsel einen nicht unwesentlichen overhead bedeuten.

Replay-Attacken, PFS.

Außerdem sollte man nie kryptographische Protokolle/Funktionen selbst implementieren/ausdenken, wie auch Nox schon sagte.
Such dir ne Bibliothek.

Für deine Zwecke wäre TLS wohl passend.

Wenn der Key RSA verschlüsselt ist, geht das natürlich. Da habe ich wohl etwas zu sehr überflogen statt im Detail zu lesen.