Socket Viele Clients bedienen mit Vert.x

Diskutiere Viele Clients bedienen mit Vert.x im Netzwerkprogrammierung Forum; Guten Abend in die Runde, momentan habe ich Schwierigkeiten, eine gute Richtung bzw. Design einer Serverstruktur für eine problemlose...

  1. Pharadox
    Pharadox Mitglied
    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?

    [​IMG]

    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
     
  2. Vielleicht hilft dir dieser Java-Kurs hier weiter --> (hier klicken)
  3. thecain
    thecain Aktives Mitglied
    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
     
  4. Pharadox
    Pharadox Mitglied
    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?
     
  5. Sasuke
    Sasuke Mitglied
    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
     
  6. Pharadox
    Pharadox Mitglied
    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!
     
  7. Sasuke
    Sasuke Mitglied
    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
     
  8. Pharadox
    Pharadox Mitglied
    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.)
     
  9. Sasuke
    Sasuke Mitglied
    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
     
  10. JuKu
    JuKu Mitglied
    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:

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

    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.

    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.

    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.

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

    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).

    Was meinst du genau?

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

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

    Ja. Definitv!
    Solltest du auch bei deinem Vorhaben.
     
  11. JuKu
    JuKu Mitglied
    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?
     
Die Seite wird geladen...

Viele Clients bedienen mit Vert.x - Ähnliche Themen

Viele Clients ein Server
Viele Clients ein Server im Forum Netzwerkprogrammierung
RMI: Wieviele Clients können sich gleichzeitig anmelden?
RMI: Wieviele Clients können sich gleichzeitig anmelden? im Forum Netzwerkprogrammierung
Netzwerk Betrachtung mit vielen Clients
Netzwerk Betrachtung mit vielen Clients im Forum Netzwerkprogrammierung
gleichzeitiges Ansprechen vieler Textfelder
gleichzeitiges Ansprechen vieler Textfelder im Forum Java Basics - Anfänger-Themen
Modaler Dialog und JTree Node mit sehr... seeeeehr vielen Elementen
Modaler Dialog und JTree Node mit sehr... seeeeehr vielen Elementen im Forum AWT, Swing, JavaFX & SWT
Thema: Viele Clients bedienen mit Vert.x