spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Also geht es um eine Webanwendung? Weil soweit ich weiß ist nur in dem Fall Websocket wirklich sinnvoll. Für "native" Anwendungen ist die Verwendung von HTTP(S) um eine Dauerverbindung auszuhandeln nach meinem Kenntnisstand nur ein Umweg.

Und dazu noch ein ziemlich langsamer.

Was wäre denn eine bessere/schnellere Alternative?
(das Hilft dem TE bestimmt auch)

Ich kenne mich wie gesagt mit Java nicht aus und mit C# nur rudimentär, aber zumindest für C# (bzw genauer .NET) scheint es mit TcpClient/TcpListener und SslStream eine recht einfache Variante zu geben (so behauptet es zumindest Google). Ein kurzer Blick in die Doku scheint auch den Verdacht zu bestätigen, dass man damit auch asynchron bzw select artig arbeiten kann.
Für java müsste ich eben nochmal google anschmeißen bzw auf java .net verweisen, aber ich glaube das kann auch jeder für sich selbst machen.

Was ist aber, wenn ich die Software nun auch ins Web heben will?

Also Connections per Javascript erwarte? Dann habe ich das mit SignalR/Websocket direkt drin und muss nicht erst noch umplanen.

Gut, das ist sehr Anwendungsspezifisch, aber eben doch ein sehr starker Vorteil.

Noch dazu müsstest du einen Port bestimmen/freigeben über den die Anwendung läuft, um darauf horchen zu können. Bei Websocket ist es der normale HTTP(S)-Port.
Kein extra Risiko.

Ich möchte hier aber keine Grundsatzdiskussion zwischen den beiden Architekturen anfangen, beide haben Vor- und Nachteile je nach Anwendung.

Darum fragte ich ob es sich um eine Webanwendung handelt. In den genannten Specs steht auch nichts von wegen Webanwendung. Natürlich kann es vorteilhaft sein, diese Funktionalität anbieten zu können. Aber man muss sich auch der Frage stellen, ob man es braucht. Denn feature creep kann ganz schnell unangenehm werden. Auch kommen features oft nicht umsonst (overhead).

Das mit der Portfreigabe ist übrigens ein amüsantes Argument. Immerhin muss der Port 80 bzw 8080 ja auch freigegeben werden. Was nun eine Freigabe auf einem anderen Port mit (zusätzlichem) Risiko zu tun hat weiß ich nicht. Prinzipiell kann man an jeden (frei verfügbaren) Port auch beliebiges hängen. Das auf 80/8080 ein Webserver antwortet ist ja nur Konvention und kein muss soweit ich weiß.

TL;DR

Websocket gut für Webanwendung. Websocket nicht automatisch beste Lösung für andere Anwendungen.

Zitat von »Nox«

Prinzipiell kann man an jeden (frei verfügbaren) Port auch beliebiges hängen. Das auf 80/8080 ein Webserver antwortet ist ja nur Konvention und kein muss soweit ich weiß.

Das ist richtig. Was du über welchen Port anstellst ist egal. Du kannst deinen Webserver auch auf Port 1337 laufen lassen wenn du möchtest, und genau so gut kannst du auf Port 80 beliebige andere Anwendungen, bzw Protokolle laufen lassen.

Zitat von »birdfreeyahoo«

Im Moment ist er so implementiert, dass ein Thread auf neue Verbindungen wartet und für jeden Client ein neuer Thread hinzukommt.

Das ist mit das schlechteste, was du machen kannst und skaliert gar nicht gut.
Erstens gibt es z.B. unter Linux Limits, was die maximale Anzahl der Threads betrifft. Wenn ich mich nicht irre, dann darf ein Prozess unter Linux standardmäßig maximal 32 Threads öffnen.
Das Limit kann man aber anheben - allerdings ist es nicht umsonst gemacht.
Zweitens wird damit dein ganzer Server langsam, da das Betriebssystem die Threads alle in den Zyklus einweisen muss. Das kostet wertvolle Rechenzeit.
Besser: Thread Pools benutzen!

Zitat von »birdfreeyahoo«

Zusätzlich ist es so, dass für jede Message eine neue Verbindung aufgebaut wird (und dann direkt wieder geschlossen wird). Das möchte ich abschaffen und auf eine konstante Verbindung setzen, da sowieso jede 10 Sekunden eine Nachricht geschickt wird und der Server auch auf seine Initiative Nachrichten schicken können soll.

Das solltest du auch unbedingt machen!
Denn der Verbindungsaufbau kostet dich nur unnötig Zeit (Stichwort TCP_NODELAY, Nagel Algorithmus & Co.).
Unbedingt die Verbindung halten!

Zitat von »birdfreeyahoo«

Im Moment sind es nur ugf. 200, die aber nicht parallel laufen sondern immer erzeugt und zerstört werden (z.B. auf Programm-Ebene) wenn einer der 200 User was machen will. Sollte ich es vermeiden so viele Threads zu haben?

Definitiv ja!
Ich glaube auch nicht, dass du auf 200 Threads (innerhalb eines Prozesses) kommen wirst.
Prinzipiell gilt die Faustregel: Anzahl Threads = Anzahl CPU Cores * 2.
Damit kommt die Hardwar am besten zurecht. Also bei einem Intel mit 8 Cores max. 16 Threads in den Thread Pool.
Alles andere bringt dir keinen Vorteil, da deine CPU nun mal nicht mehr Threads gleichzeitig abarbeiten kann, stattdessen erzeugst du nur Verwaltungsoverhead fürs Betriebssystem.

Zitat von »birdfreeyahoo«

Ich hatte neulich einen Bug dass ein TimerTask der jede 3 Minuten ausgeführt werden sollte (scheduleAtFixedRate) einfach nicht mehr gelaufen ist und der Server neugestartet werden musste.

Ja, das kann ich mir sehr gut vorstellen!
Bei 600 Threads kommt der einzelne nicht mehr (bzw. kaum noch) zum Zug!

Zitat von »birdfreeyahoo«

Bisher läuft das noch relativ gut, d.h. es werden keine Verbindungen oder laufende Threads einfach gedroppt.

Das ist auch gar nicht möglich.
Das Betriebssystem killt entweder deinen gesamten Prozess oder gar nicht, aber nicht einzelne Threads.
Und ob die Verbindungen disconnecten merkst du ohne TCP Keep Alive gar nicht.
Siehe auch https://www.tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html.

Zitat von »birdfreeyahoo«

Mein alternativer Ansatz wäre, in einem Thread einen Selector laufen zu lassen, der bei einem Event (Accept/Read) einen Thread aus einem ThreadPool disponiert, der den Request verarbeitet und im selben Thread falls nötig eine Response sendet.

So in etwa ist das Standardvorgehen bei den meisten Libraries wie z.B. Netty.

Zitat von »birdfreeyahoo«

Die Gefahr die ich da sehe ist, dass ein Bottleneck dadurch entsteht, dass der Pool keine Threads mehr hat.
Welche Werte sind da empfohlen als Maximum?

Wie oben bereits geschrieben:
Maximum Anzahl Threads = CPU Cores * 2.
Deine CPU kann nur so viele Threads gleichzeitig abarbeiten, d.h. wenn der Pool keine Threads mehr hat, macht das überhaupt keinen Unterschied, weil deine CPU sowieso nicht mehr Threads gleichzeitig handeln könnte. Von daher ist das dann auch kein von dir erzeugtes Bottleneck, sondern das Bottleneck der CPU.

Zitat von »birdfreeyahoo«

Die Operationen in den Threads sind hauptsächlich Datenbankoperationen und Network-Stream-Writes, die dann am besten asynchron erfolgen.

Datenbank-Zugriffe wenn möglich in einem eigenen Thread Pool. Kann man am besten reactive lösen.
Sodass dein Thread erst "aufwacht" bzw. den Callback Handler ausführt, wenn die Ergebnisse von der Datenbank da sind.

EDIT:
Ach und wenn es sich um eine Java Anwendung handelt, dann schau dir am besten mal vertx.io an. Da sind Thread Pools & Co. alles schon enthalten.