Du bist nicht angemeldet.

Werbeanzeige

Nox

Supermoderator

Beiträge: 5 274

Beruf: Student

  • Private Nachricht senden

11

27.01.2019, 21:49

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.
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

BlueCobold

Community-Fossil

Beiträge: 10 872

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

12

27.01.2019, 22:12

Und dazu noch ein ziemlich langsamer.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Goldwing Studios

Treue Seele

Beiträge: 357

Wohnort: Heidelberg

Beruf: Softwareentwickler, Vertriebler

  • Private Nachricht senden

13

28.01.2019, 09:31

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

birdfreeyahoo

Alter Hase

  • »birdfreeyahoo« ist der Autor dieses Themas

Beiträge: 766

Wohnort: Schorndorf

Beruf: Junior Software Engineer

  • Private Nachricht senden

14

28.01.2019, 16:24

Was mir wichtig ist:
- beidseitige Kommunikation zu beliebigem Zeitpunkt
- TCP-basiert mit SSL-Verschlüsselungsoption
- Verfügbarkeit für C# und Java

Bei Websocket fand ich die Schnittstelle toll mit den Callbacks (das ist eigentlich das was ich will), sowie der automatische Heartbeat-Mechanismus.

Nox

Supermoderator

Beiträge: 5 274

Beruf: Student

  • Private Nachricht senden

15

28.01.2019, 20:08

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.
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

Goldwing Studios

Treue Seele

Beiträge: 357

Wohnort: Heidelberg

Beruf: Softwareentwickler, Vertriebler

  • Private Nachricht senden

16

29.01.2019, 09:56

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.

Nox

Supermoderator

Beiträge: 5 274

Beruf: Student

  • Private Nachricht senden

17

29.01.2019, 13:15

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.
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

Schorsch

Supermoderator

Beiträge: 5 185

Wohnort: Wickede

Beruf: Student

  • Private Nachricht senden

18

29.01.2019, 13:21

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.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

birdfreeyahoo

Alter Hase

  • »birdfreeyahoo« ist der Autor dieses Themas

Beiträge: 766

Wohnort: Schorndorf

Beruf: Junior Software Engineer

  • Private Nachricht senden

19

29.01.2019, 15:22

Also es ist eher unrealistisch dass das eine Webanwendung wird. Port ist auch gar kein Problem. Die nativen TCP-Schnittstellen der jeweiligen Standardbibliotheken sind bisher auch in Verwendung. Ich überarbeite den Teil nur und hatte auch ein Auge auf Websocket geworfen. Bei der eigenen Implementierung muss man eben noch auf mehr achten bzw. mehr selber machen.

20

13.04.2019, 22:58


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!


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!


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.


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!


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.


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.


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.


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.
Indie Game-Dev Programmierer beim 2D MMORPG Pentaquin | Pentaquin Foren Vorstellung

Werbeanzeige