Socket Viele Clients bedienen mit Vert.x

[Pharadox]

Guten Abend in die Runde,

momentan habe ich Schwierigkeiten, eine gute Richtung bzw. Design einer Serverstruktur für eine problemlose Kommunikation vieler Clients, welche mobil online sind (Abbrüche drohen) und den oder die Server dann mit Anfragen bombardieren. Eventuell hilft soetwas ausgereiftes wie Netty oder Vert.x bei der ganzen Problematik?

So wie ich mir das bisher ausgedacht habe:
Server
Eine Java-Applikation lauscht an einem Port auf eintreffende Verbindungen und delegiert diese an leere Threads oder erstellt pro Verbindung einen neuen. Dafür nutzt die Applikation diese Non-Blocking I/O für die Sockets, um die Anfragen asynchron abhandeln zu können (Dazu muss ich mir noch einiges durchlesen, da noch nicht ganz verstanden. Vor allem Wiederaufnahme einer abgebrochenen Verbindung, wenn z.B. in Verbindung 1 nur ein Teil des Requests eintrifft und der restliche in Verbindung 2 und anschließend erst die vollständig gesendeten Informationen der Client-App vorliegen. Eventuell erübrigt sich das, dank Vert.x oder Netty).
Werden es zuviele Verbindungen (ich rechne vorsorglich mit 1Mio), werden keine neuen Threads mehr erzeugt, um der Gefahr eines Absturzes zu verhindern und die Verbindung landet in einer Warteschlange. (Was schlecht wäre, da die Client-App schon schnell die Information braucht)
1. Java Applikation startet
2. Prüft, wieviele CPU Kerne und Memory zur Verfügung stehen
3. Erzeugt auf Basis dessen mehrere wartende Threads und ein Maximum an erlaubten
4. Eine Warteschlange wird erzeugt
5. Thread, der nur für die Verbindungsdelegation erstellt wurde, lauscht an einem Port und delegiert eingetroffene Verbindungen an Threads zur Abarbeitung


Den Ablauf der Kommunikation denke ich mir so:
1. App nimmt Verbindung mit Server auf (im gesendeten Paket ist gleich die Information enthalten, was die App vom Server möchte, also ob Login, Registrierung, Daten)
2. Server nimmt die Verbindung an, wenn Client-App sich mittels validen Login vorher authentifiziert und dadurch quasi eine Session erhalten hat, die für einen bestimmten Zeitraum gültig ist, falls die App in wenigen Minuten oder ein paar Stunden erneut eine Anfrage tätigt und somit nicht erneut den Authentifizierungsvorgang starten muss
3. Server verarbeitet (zieht die Daten aus der DB) den Request und hält solange die Verbindung (damit nicht zu lange, Timeout?) bis der Client satt ist.

Ich habe bei Vert.x gesehen, dass es sehr viele Componenten gibt, wodurch auch eine direkte Verbindung zur Datenbank möglich wäre. Das darf aber nicht sein, da sonst in die Android App Tabellennamen oder Verbindungsinformationen zur DB enthalten würde.

Fragen:
- Datenverkehr sichern mittels SSL/TLS macht keine Performance-Probleme?
- Wie umgehen mit Verbindungsabbrüchen zur Client-App und Client-App versuche, mehrmals gleiche Operation anzufragen? Gefahr der Entstehung eines DDoS!
- Java NIO? Asynchrones Verhalten der Threads liefert Client-Apps nicht sofort Daten?
- Threadlimitierung durch Memory überwachen oder Threadpool?
- Reuse von Objekten speziell Threads?
- Extra Prozesse starten für Abarbeitungs-Threads?
- Kann ich dieses komplette Verbindungs- und Threadmanagement an Vert.x übergeben?
- Was würdet ihr verändern?

Ich bedanke mich.
MfG

 

[thecain]

Hast du denn schon ein Problem oder sind das nur gedankenspiele. Ich würde nicht optimieren wo es nichts zu optimieren gibt.

Wenn es dann auftritt siehst du auch wo das Problem tatsächlich liegt

 

[Pharadox]

Das Problem ist, dass ich nicht weiß, ob dieses Softwaredesign so funktionieren kann oder ob ich nicht eher genau sowas nachbauen würde wie Vert.x bzw. Netty schon ist?

 

[Sasuke]

Hey,

Frameworks wie Netty nachzubauen ist eine Mamutaufgabe, nichts was man mal eben so nebenbei für ein anderen Projekt macht . Ich würde dir empfehlen, die Kommunikation auf etwas REST artiges umzubauen. Mit Mobilgeräten durchgehend Verbindungen offenzuhalten ist immer eine Sache. Zum einen hast du wie du schon erkannt hast das Problem von abbrechenden Verbindungen, zum anderen können andauernde Verbindungen sich natürlich auf die Auslastung und den Stromverbrauch des Gerätes auswirken.

Es lässt sich http://square.github.io/okhttp/ als Client Library empfehlen, die Serverseite überlasse ich dir.

Eine direkte Verbindung zur Datenbank ist natürlich total... uncooler Umgang. Die Datenbank kannst du komplett hinter deinem REST Service verstecken.

Mit freundlichen Grüßen
Sasuke

 

[Pharadox]

Ich möchte das nicht nachbauen, nur verstehen, ob das, was ich vorhabe, nicht genau das ist, was Netty oder Vert.x quasi sowieso schon im Kern machen?

Also ich benötige keine persistente Verbindung zu Mobilgeräten. Aber die Problematik mit Verbindungsabbruch und erneutem Aufbau sehe ich schon als Last und Gefahr. Aber vllt. bietet auch hierzu Netty/Vert.x bereits integrierte Lösungen. Nur ist es für mich schwer, die genaue Funktionsweise/Umfang in Erfahrung zu bringen.

Wieso auf REST? Wenn die Requests erst über einen HTTP-Server laufen müssen, kostet das doch eher mehr Ressourcen als wenn direkt per Socket!?


Danke für euren Rat!

 

[Sasuke]

Ich möchte das nicht nachbauen, nur verstehen, ob das, was ich vorhabe, nicht genau das ist, was Netty oder Vert.x quasi sowieso schon im Kern machen?

Also ich benötige keine persistente Verbindung zu Mobilgeräten. Aber die Problematik mit Verbindungsabbruch und erneutem Aufbau sehe ich schon als Last und Gefahr. Aber vllt. bietet auch hierzu Netty/Vert.x bereits integrierte Lösungen. Nur ist es für mich schwer, die genaue Funktionsweise/Umfang in Erfahrung zu bringen.

Wieso auf REST? Wenn die Requests erst über einen HTTP-Server laufen müssen, kostet das doch eher mehr Ressourcen als wenn direkt per Socket!?


Danke für euren Rat!

Hey,

was die im Kern machen ist für viele eine Blackbox. Aber Netty zum Beispiel hat mit dem Aufbau auf NIO eben einen Fokus auf Non Blocking IO und will es vereinfachen, Netzwerkapplikationen mit Fokus auf das Bauen von Implementieren von Protokollen zu entwickeln. Durch hervorragendes Buffer Management kann man einfach sehr viel aus seinem Netzwerk rausholen.

REST empfehle ich dir aufgrund der oben genannten Verbindungsproblematik. Eine "automische Neuverbindung nach Abbruch" hat Netty zwar nicht, die Implementierung wäre jedoch ein Kinderspiel. Welche Funktionsweise und welchen Umfang von was möchtest du denn genau wissen?

Letzendlich sind es alles Bytes, denen ist das Protokoll egal. Über die Performance und die Ressourcen kann man immer streiten, sie sollten jedoch jetzt noch nicht im Fokus stehen. HTTP bietet dir ein vorhandenes etabliertes Protokoll, REST Schnittstellen findest du zuhauf. Alles mit Sockets selber zu entwickeln kann je nach Ziel sehr aufwendig sein. Desweiteren hast du durch REST eine sehr saubere Schnittstelle und kannst Verbindungsprobleme sehr elegant behandeln.

Mit freundlichen Grüßen
Sasuke

 

[Pharadox]

Einfachstes Beispiel wäre Pokemon Go!
Die haben gewaltige Mengen an Spielern mit Daten zu versorgen. Server die unter Dauerfeuer stehen. Soweit ich weiß hatten sie zu Beginn große Probleme mit ihren Login-Servern.

Was werden die wohl für eine Infrastruktur aufgebaut haben? (Nur von einem einzelnen Server auf einem Kontinent ausgehend.)

 

[Sasuke]

Einfachstes Beispiel wäre Pokemon Go!
Die haben gewaltige Mengen an Spielern mit Daten zu versorgen. Server die unter Dauerfeuer stehen. Soweit ich weiß hatten sie zu Beginn große Probleme mit ihren Login-Servern.

Was werden die wohl für eine Infrastruktur aufgebaut haben? (Nur von einem einzelnen Server auf einem Kontinent ausgehend.)

Hey,

ich habe mich nie wirklich mit Pokemon GO beschäftigt und die Gründe für Serverprobleme sind manigfaltig. Überlastete Datenbanken, nicht ausreichende Netzwerkanbindung, ausgefallene Server - Alles kann das sein.

Wenn du wissen willst was sie aufgebaut haben fragst du am besten, viele Entwickler geben gerne Auskunft, je nachdem wie komerziell ihr Projekt ist Gängige Praxis für sowas wäre REST.

Mit freundlichen Grüßen
Sasuke

 

[JuKu]

Ich kann dir nur vertx.io empfehlen. Ist eine Library, die auf Netty basiert und nochmal mehr weg abstrahiert, was gerade für dich vllt. interessant sein könnte.

Außerdem habe ich mal ein Tutorial geschrieben, wie man einen Chat Server + Client in vertx.io implementiert:

• Ein Chat Server in Java - Teil 1 / 2
• Ein Chat Server in Java - Teil 2 / 2

So wie ich das sehe deckt es genau deinen Use Case ab.

Eine Java-Applikation lauscht an einem Port auf eintreffende Verbindungen und delegiert diese an leere Threads oder erstellt pro Verbindung einen neuen.

Für jede Verbindung einen Thread zu erstellen, ist das schlimmste, was du machen kannst. Das wird deinen Computer sehr schnell auslasten. Stattdessen solltest du Thread Pools nutzen, Stichwort Executor Service.

Werden es zuviele Verbindungen (ich rechne vorsorglich mit 1Mio), werden keine neuen Threads mehr erzeugt, um der Gefahr eines Absturzes zu verhindern und die Verbindung landet in einer Warteschlange. (Was schlecht wäre, da die Client-App schon schnell die Information braucht)

1 Mio. Verbindungen? Was willst du denn programmieren?
Wenn du nicht gerade einen Super Computer zu Hause stehen hast, wird dein Computer bei effizienter Software maximal 40.000 Connections schaffen. Das ist eine rein geschätzte Zahl, aber dass du mehr schaffst, glaube ich fast nicht. Wenn du wirklich so viele Verbindungen offen halten müsstest, müsstest du die Server skalieren (Stichwort: scaling out), das wird aber sehr schwierig, wenn du noch nie was mit Networking zu tun hattest.

Ich habe bei Vert.x gesehen, dass es sehr viele Componenten gibt, wodurch auch eine direkte Verbindung zur Datenbank möglich wäre. Das darf aber nicht sein, da sonst in die Android App Tabellennamen oder Verbindungsinformationen zur DB enthalten würde.

Die App darf sowieso keine Daten zur Datenbank besitzen. Braucht sie auch nicht. Sie fragt lediglich das Backend (dein Server) ab und nur dieses greift auf die Datenbank zu.

Fragen:
- Datenverkehr sichern mittels SSL/TLS macht keine Performance-Probleme?

Wenn es Performance-Probleme geben würde, würden dann so viele auf SSL setzen?
SSL zieht kaum Performance, zumindest nicht merklich.

- Wie umgehen mit Verbindungsabbrüchen zur Client-App und Client-App versuche, mehrmals gleiche Operation anzufragen? Gefahr der Entstehung eines DDoS!

Verbindung einfach wieder herstellen, mit einem Delay, z.B. 500ms. Dass ein Computer gleich einen DDOS starten soll (vorallem eine App) wäre nur mit sehr viel Fantasie möglich (meine persönliche Einschätzung).

- Java NIO? Asynchrones Verhalten der Threads liefert Client-Apps nicht sofort Daten?

Was meinst du genau?

- Threadlimitierung durch Memory überwachen oder Threadpool?

Threadpool! Nur einen Thread Pool, keine weiteren Threads erzeugen. Diesen Thread Pool kann man zur Not skalieren, sollte aber eig. nicht notwendig sein.

- Extra Prozesse starten für Abarbeitungs-Threads?

Nein. Prozesse besitzen wesentlich mehr Overhead als Threads. Nur wenn du deinen Computer schnell in die Knie zwingen willst, solltest du neue Prozesse öffnen.

- Kann ich dieses komplette Verbindungs- und Threadmanagement an Vert.x übergeben?

Ja. Definitv!
Solltest du auch bei deinem Vorhaben.

 

[JuKu]

Einfachstes Beispiel wäre Pokemon Go!
Die haben gewaltige Mengen an Spielern mit Daten zu versorgen. Server die unter Dauerfeuer stehen. Soweit ich weiß hatten sie zu Beginn große Probleme mit ihren Login-Servern.

Was werden die wohl für eine Infrastruktur aufgebaut haben? (Nur von einem einzelnen Server auf einem Kontinent ausgehend.)

Auch dazu noch was.
Pokemon Go setzt definitv nicht nur einen Server ein, sondern sehr viele. Die skalieren aus. Wäre aber für dich zu kompliziert. Und die nutzen auch vermutlich kein Rest, da Rest zu viel Overhead besitzt, sondern ein Byte Protokoll.
Die Frage ist aber: Was brauchst du?