Client / Server

[d3rbastl3r]

Ich habe bereits in einem Thread diese Frage so nebenbei gestellt. nun wollte ich mal dafür einen eigenen Thread öffnen ^^

Ich möchte ein Programm umsetzen welches Daten auf einem Server speichert und bei eventuellen Aktualisierungen informiert wird. Nun schwanke ich zwischen mehreren Modellen. JavaRMI, CORBA, Java Sockets oder doch die Kommunikation über HTTP an nen PHP-Server. Dabei geht es mir nicht um eine möglichst schnelle und komfortable Umsetzung sondern:

- Um einen möglichst sauberen Aufbau des Kommunikationsablaufs
- Möglichst hoher Performance
- Und um eine Möglichst hohe und problemlose Erweiterbarkeit des Systems

Mit allen diesen Systemen habe ich bereits Erfahrung gemacht.
JavaRMI ist meiner Ansicht nach ziemlich einfach in der Umsetzung, der Datentransfer kann wenig Overhead enthalten und die spätere Erweiterbarkeit bei einem sauber umgesetzten Programm ist optimal. Doch wie sieht es mit der Performance aus? Vor allem auf der Serverseite? Egal ob momentan hier 1 oder 100 Clients verbunden sein sollen, man nähme an es wären durchgehend Tausende von Clients, denn dieses Projekt soll nur als Vorprojekt für einen Größeren sein.

CORBA ist in meinen Augen das Performanteste System was den Server angeht, denn dieser wird in C++ Programmiert. Die Kommunikation zwischen JavaClient und C++ Server gestaltet sich jedoch nicht ganz unproblematisch. Was den Overhead angeht kann ich nichts zu sagen.

Bei Java-Sockets sehe ich keinen Vorteil gegenüber JavaRMI. Wenn ich mich irre belehrt mich eines besseren

Kommunikation über HTTP-Requests ... Hmm ... Hier müsste ein Apache-Server her der die Anfragen mit Hilfe von PHP verarbeitet. Durch das Caching-System der PHP-Abläufe als Binärdatzeien ist die Informationverarbeitung deutlich schneller als mit Java. Jedoch müssten die Daten via. JSON-Objekte versendet werden um wenig Overhead zu verursachen, was beim Parsen etwas Rechenaufwand bedeutet. Hier kann auch keine Verbindng gehalten werden, also müsste der Client regelmäßig anfragen an den Server senden um bei eventuellen Aktualisierungen auf dem neusten Stand zu bleiben.



So, jetzt habe ich viel geschrieben und möchte nun eure Meinung wissen was das beste System ist um die og. Anforderungen zu erfüllen?

 

[homer65]

So ein HTTP Server hatt schon Konzepte implementiert, die du bei RMI, CORBA oder Sockets selber einbauen müßtest.
Beispiel: Bei vielen gleichzeitig aktiven Clients macht es Sinn nicht für jeden Client sofort einen eigenen Thread zu starten, sondern einen Pool von Thread zu nutzen, bei dem nur eine maximale Anzahl von Threads aktiv ist.

 

[d3rbastl3r]

So ein HTTP Server hatt schon Konzepte implementiert, die du bei RMI, CORBA oder Sockets selber einbauen müßtest.
Beispiel: Bei vielen gleichzeitig aktiven Clients macht es Sinn nicht für jeden Client sofort einen eigenen Thread zu starten, sondern einen Pool von Thread zu nutzen, bei dem nur eine maximale Anzahl von Threads aktiv ist.

Ist eine HTTP / RMI Kombination zu empfehlen?

Datenübertragung Server -> Client mit RMI (Halten einer Verbindung) um gewisse Informationen in Echtzeit anzeigen zu können (Mehrere Threads nicht unbedingt notwendig).

Datenübertragung Client -> Server über HTTP wenn Daten in der Datenbank gesichert werden sollen (wobei kriegt dann der RMI-Server die Aktualisierung eventuell nicht mit)

 

[ARadauer]

ich würd mir 19. Remoting and web services using Spring ansehen... haben damit und Hessian Binary Web Service Protocol gute erfahrungen gemacht

 

[Bernd Hohmann]

Ich möchte ein Programm umsetzen welches Daten auf einem Server speichert und bei eventuellen Aktualisierungen informiert wird.

Wer informiert wen? Server den Client? Vieviel muss der Server an den Client schicken? Reicht es wenn der Client sporadisch den Server nach Änderungen fragt oder muss das Zeitnah passieren?

Welche Datenmengen welcher Form sollen da fliessen? Kleine Häppchen oder mehrere MB?

Bei letzterem würde ich mich nach dem richten, was Akamai cachen kann (also HTTP), kurze Blöcke bekommt man noch mit eigener Infrastruktur hin.

Bernd

 

[d3rbastl3r]

ich würd mir 19.*Remoting and web services using Spring ansehen... haben damit und Hessian Binary Web Service Protocol gute erfahrungen gemacht

Hessian 2 klingt vielversprechend, vor allem was Performance angeht, wobei RMI und ORMI ähnliche Performance aufweisen.
Spring und JBeans würde ich meiden da diese sehr Unperformant sind und bei Größeren Projekten den Rechner in die Knie zwingen. Vor allem Java Reflection was unter JBeans verwendet wird zieht an der Leistung.

Wer informiert wen? Server den Client? Vieviel muss der Server an den Client schicken? Reicht es wenn der Client sporadisch den Server nach Änderungen fragt oder muss das Zeitnah passieren?

Welche Datenmengen welcher Form sollen da fliessen? Kleine Häppchen oder mehrere MB?

Bei letzterem würde ich mich nach dem richten, was Akamai cachen kann (also HTTP), kurze Blöcke bekommt man noch mit eigener Infrastruktur hin.

Bernd

Der Client soll Daten auf dem Server speichern. Der Server soll aber auch den Client mit Daten versorgen können.

Momentan bin ich noch an einem "Launcher" dran. Dieser soll einerseits Benutzer registrieren können und die Authentifizierung der Daten durchführen, was eine ziemlich kleine Datenmenge ausmacht. Andererseits soll dieser die Eigentliche Software initialisieren können, zuvor aber muss diese Software nach Updates geprüft und gegebenenfalls die Updates geladen werden. Dies könnte auch mehrere MB Groß werden.

 

[Bernd Hohmann]

Der Client soll Daten auf dem Server speichern. Der Server soll aber auch den Client mit Daten versorgen können.

Das hab ich schon verstanden, aber geht die Aktion dann vom Server aus oder ist es eher so wie "WEB 2.0" (Client schiebt Bilder auf den Server und holt sie auch wieder ab) ?

Da muss man schon vorne gut überlegen was man hinten haben möchte.

Es hindert Dich ja niemand daran, einen eigenen Server zu schreiben der mit paar Workerthreads den Kram entgegennimmt. Aber denke daran: die meissten Miet-Rechner sind mit 100MBit am Rack-Switch angebunden und wenn das ganze Rack mit 1GBit angeschlossen ist, ists schon Luxus.

Könnte also sein, dass Du Probleme an einer ganz anderen Stelle bekommst.

Bernd

 

[d3rbastl3r]

Das hab ich schon verstanden, aber geht die Aktion dann vom Server aus oder ist es eher so wie "WEB 2.0" (Client schiebt Bilder auf den Server und holt sie auch wieder ab) ?

Der Launcher könnte sich in der Tat immer selbst die Informationen von dem Server abholen (sowie Updates). Aber das Spätere Programm soll Benutzern einer Gruppe es erlauben an einer Plannung gleichzeitig zu Arbeiten. Dies setzt natürlich voraus, dass alle die Aktualisierungen anderer in Echtzeit mitbekommen (das heißt: verschiebt ein Benutzer ein Modul so sehen alle anderen wie das Modul verschoben wird). Aber auch ein Gruppen-Chat sollte (denke ich) über eine bestehende Verbindung realisiert werden.

Wobei die oben genannten Datentransfers sind nur wenige KB groß wenn nicht sogar wenige Bytes. Ich meine um von einem Modul die Position zu aktualisieren sinds vielleicht:
Id des Moduls als Int = 32Byte
XY-Koordinaten als Float oder Int = 64Byte
plus einpaar Referenzen und Overhead macht max. 256Byte pro Übertragung???

Es hindert Dich ja niemand daran, einen eigenen Server zu schreiben der mit paar Workerthreads den Kram entgegennimmt. Aber denke daran: die meissten Miet-Rechner sind mit 100MBit am Rack-Switch angebunden und wenn das ganze Rack mit 1GBit angeschlossen ist, ists schon Luxus.

Könnte also sein, dass Du Probleme an einer ganz anderen Stelle bekommst.

Bernd

Es ist in der Tat so dass mein Miet-Server nur eine 100MBit Anbindung hat. In wie fern ist das ein Problem? Könnte es sein, dass die Anbindung eher ausgelastet ist als der Rechner selbst? Habe damit noch keine Erfahrungen gemacht.

 

[Templarthelast]

Ein Client kommuniziert immer nur mit einem Server. Der Server dagegen kommuniziert mit meheren Clients gleichzeitig. Wenn es einen Chat mit 4 Leuten gibt sendet jeder Client nur 256byte, der Server allerdings 1 kb. Das ganze skaliert mit der Anzahl der Benutzer und der Informationsdichte sehr schnell hoch und wenn du währenddesen auch noch updates verteilen willst, könnte es mit einer flüssigen Übertragung schwieriger werden. Wenn du vorhast ein solches System für viele Leute gleichzeitig auszulegen, würde ich netzwerkintensive Tätigkeiten, wie z.B. das Bereitstellen eines Downloades auslagern. Es macht für den Nutzer wohl kaum einen Unterschied, wenn das update langsamer geladen wird, solange die eigentliche Funktionalität nicht eingeschränkt wird.

 

[Bernd Hohmann]

Es ist in der Tat so dass mein Miet-Server nur eine 100MBit Anbindung hat. In wie fern ist das ein Problem? Könnte es sein, dass die Anbindung eher ausgelastet ist als der Rechner selbst? Habe damit noch keine Erfahrungen gemacht.

Denk mal an die heutigen DSL-Bandbreiten, drei User aus einer Großstadt machen Dir schnell den Server dicht wenn die einen grösseren Download machen.

Da müsste man also überlegen (wie es Templarthelast schon gesagt hat) dass man gleich an eine Verteilung denkt. Also zumindest vorsehen, dass die Downloads an einen anderen Server weitergeleitet werden können. Wird das noch grösser und die User verteilen sich noch dazu über mehrere Länder, braucht man mehrere Server die möglichst nahe an den Usern stehen. Recht komplexes Thema.

Bernd

 

[d3rbastl3r]

Ein Client kommuniziert immer nur mit einem Server. Der Server dagegen kommuniziert mit meheren Clients gleichzeitig. Wenn es einen Chat mit 4 Leuten gibt sendet jeder Client nur 256byte, der Server allerdings 1 kb. Das ganze skaliert mit der Anzahl der Benutzer

Das ist mir klar. Die benötigte Bandbreite steigt sogar mit n*(n-1), wobei n die Anzahl der Benutzer in einer Gruppe darstellt. Das heißt wenn jeder Client 256Byte sendet, muss der Server 3072Byte versenden.

und der Informationsdichte sehr schnell hoch und wenn du währenddesen auch noch updates verteilen willst, könnte es mit einer flüssigen Übertragung schwieriger werden. Wenn du vorhast ein solches System für viele Leute gleichzeitig auszulegen, würde ich netzwerkintensive Tätigkeiten, wie z.B. das Bereitstellen eines Downloades auslagern. Es macht für den Nutzer wohl kaum einen Unterschied, wenn das update langsamer geladen wird, solange die eigentliche Funktionalität nicht eingeschränkt wird.

Denk mal an die heutigen DSL-Bandbreiten, drei User aus einer Großstadt machen Dir schnell den Server dicht wenn die einen grösseren Download machen.

Da müsste man also überlegen (wie es Templarthelast schon gesagt hat) dass man gleich an eine Verteilung denkt. Also zumindest vorsehen, dass die Downloads an einen anderen Server weitergeleitet werden können. Wird das noch grösser und die User verteilen sich noch dazu über mehrere Länder, braucht man mehrere Server die möglichst nahe an den Usern stehen. Recht komplexes Thema.

Bernd

Das ist allerdings ein Argument und eine sehr gute Idee.
z.B.: Der Launcher bekommt mit, dass etwas upgedatet werden kann und gleichzeitig einen Link zu den einzelnen Paketen. Die Pakete könnten sich überall befinden.
Dann hätte man schonmal nicht das Problem was man so von einigen spielen kennt: Kommt ein Update raus so lässt sich das Spiel halben Tag, wegen hohem Ping, nicht mehr spielen.


Also den Download der Updates löhnt es sich über HTTP / FTP zu lösen. Eine Einfache Verlagerung der Updates auf beliebige Server macht das ganze sehr Flexibel.

Für die restliche Kommunikation muss ich mir wohl einen eigenen Server schreiben. Nur mal überlegen ob RMI, ORMI oder Hessian 2.

Aber die Aufteilung gefällt mir schonmal sehr gut

 

[Bernd Hohmann]

Für die restliche Kommunikation muss ich mir wohl einen eigenen Server schreiben. Nur mal überlegen ob RMI, ORMI oder Hessian 2.

"Echtes" RMI würde ich solange nicht nehmen bis Du dir einen Hiwi einstellen kannst der sich nur um dieses Thema kümmert

Ausserdem willst Du ja eigentlich nur recht banale Nachrichten versenden und nicht mit irgendwelchen Klassen auf der anderen Seite spielen.

Ich würde erstmal überlegen, welche Messagetypen da überhaupt durchlaufen sollen und dann mit einer paar MessageClasses arbeiten (MessageText, MessageBinary) die sich selber händisch über den Socket-Stream versenden und auf der anderen Seite wieder auflösen. Also alles auf recht schmalem Fuß und unter eigener Kontrolle.

Bernd

 

[tfa]

"Echtes" RMI würde ich solange nicht nehmen bis Du dir einen Hiwi einstellen kannst der sich nur um dieses Thema kümmert

Warum das? RMI ist so einfach. jedenfalls einfacher, als irgendwelche Binärdaten über Sockets zu senden und händisch auseinander zu nehmen. Noch einfacher wäre etwa eine Lösung mit Spring, aber das hat der TO ja schon ausgeschlossen (aus mir unverständlichen Gründen).

 

[Bernd Hohmann]

Warum das? RMI ist so einfach. jedenfalls einfacher, als irgendwelche Binärdaten über Sockets zu senden und händisch auseinander zu nehmen. Noch einfacher wäre etwa eine Lösung mit Spring, aber das hat der TO ja schon ausgeschlossen (aus mir unverständlichen Gründen).

RMI ist ein Panzer mit VW Golf Cockpit. Das schwerfällige Fahrverhalten merkt man erst, wenn man vom Testgelände runter ist

Bernd

 

[d3rbastl3r]

"Echtes" RMI würde ich solange nicht nehmen bis Du dir einen Hiwi einstellen kannst der sich nur um dieses Thema kümmert

Ausserdem willst Du ja eigentlich nur recht banale Nachrichten versenden und nicht mit irgendwelchen Klassen auf der anderen Seite spielen.

Ich würde erstmal überlegen, welche Messagetypen da überhaupt durchlaufen sollen und dann mit einer paar MessageClasses arbeiten (MessageText, MessageBinary) die sich selber händisch über den Socket-Stream versenden und auf der anderen Seite wieder auflösen. Also alles auf recht schmalem Fuß und unter eigener Kontrolle.

Bernd

Hmm, habe mit RMI schon gearbeitet und fands ziemlich simpel.
Mit RMI lassen sich aber auch Binärdaten recht einfach versenden. Die Objekte die mit RMI übermittelt werden, werden meiner Erfahrung nach erst Serialisiert und am anderem Ende desirealisiert (bzw. alles was über den ObjectStream geht). Überschreibt man die readObject und writeObject von Serializable so kann man nur die Binärdaten über den Stream jagen (mit minimalem Overhead) ^^
Oder habe ich RMI nicht richtig verstanden ?

Die Daten sollen sich ja auch nicht auf die Id, X- und Y-Koordinate beschränken ... tatsächlich sind es mehrere Objekttypen die Positioniert werden können die zusätzliche Eigenschaften enthalten.

Warum das? RMI ist so einfach. jedenfalls einfacher, als irgendwelche Binärdaten über Sockets zu senden und händisch auseinander zu nehmen. Noch einfacher wäre etwa eine Lösung mit Spring, aber das hat der TO ja schon ausgeschlossen (aus mir unverständlichen Gründen).

Mit JBeans / Spring habe ich bereits Erfahrung gemacht. Das ganze lässt sich ziemlich sauber umsetzen, gar keine Frage. Was mich stört ist, dass JBeans durch die Verwendung von Java-Reflection ziemlich viel Rechenaufwand kostet. Oder ich übersehe was ...

 

[Bernd Hohmann]

Die Objekte die mit RMI übermittelt werden, werden meiner Erfahrung nach erst Serialisiert und am anderem Ende desirealisiert (bzw. alles was über den ObjectStream geht). [...] Oder ich übersehe was ...

Nein, Du hast das Problem schon erkannt.

Bernd

 

[tfa]

RMI ist ein Panzer mit VW Golf Cockpit. Das schwerfällige Fahrverhalten merkt man erst, wenn man vom Testgelände runter ist

Seltsam. Wir haben hier gut funktionierende Projekte im produktiven Einsatz, die u.a. RMI und Spring verwenden - im weltweiten Firmen-Intranet mit 10000en Anwendern in zufriedenstellender Performance. Ist natürlich auch eine Hardwarefrage. Aber wenn ich alles verteufeln würde, was Reflection verwendet, wegen vermuteter Performanceprobleme, müsste ich mir einen anderen Job suchen.

 

[d3rbastl3r]

RMI ist ein Panzer mit VW Golf Cockpit. Das schwerfällige Fahrverhalten merkt man erst, wenn man vom Testgelände runter ist

Bernd

Und welches System empfiehlst du für den Transport komplexerer Datenstrukturen? Momentan hört sich das nach Java-Sockets an xD

Seltsam. Wir haben hier gut funktionierende Projekte im produktiven Einsatz, die u.a. RMI und Spring verwenden - im weltweiten Firmen-Intranet mit 10000en Anwendern in zufriedenstellender Performance. Ist natürlich auch eine Hardwarefrage. Aber wenn ich alles verteufeln würde, was Reflection verwendet, wegen vermuteter Performanceprobleme, müsste ich mir einen anderen Job suchen.

Naja, ich verteufle Reflection nicht wirklich Finde nur den Einsatz von Reflection in Serveranwendungen etwas ungeeignen ^^ Vor allem wenn es um eine ziemlich geringe Leistung eines VServers geht.

 

[tfa]

Naja, ich verteufle Reflection nicht wirklich Finde nur den Einsatz von Reflection in Serveranwendungen etwas ungeeignen ^^ Vor allem wenn es um eine ziemlich geringe Leistung eines VServers geht.

Der Glaube, Reflection sei langsam, ist ziemlich alt. Früher, so in den 90er Jahren stimmte, das sicherlich noch. Aber auf einer modernen VM ist der Performance-Unterschied zu vernachlässigen.

 

[Bernd Hohmann]

Seltsam. Wir haben hier gut funktionierende Projekte im produktiven Einsatz, die u.a. RMI und Spring verwenden - im weltweiten Firmen-Intranet mit 10000en Anwendern in zufriedenstellender Performance. Ist natürlich auch eine Hardwarefrage. Aber wenn ich alles verteufeln würde, was Reflection verwendet, wegen vermuteter Performanceprobleme, müsste ich mir einen anderen Job suchen.

Natürlich funktioniert RMI ganz prima und die Performance ist auch nicht zu verachten. Ich mags nur deshalb nicht weil es im Ernstfall alle Probleme der Serialisierung mit sich bringt. Sowas da zb: http://www.java-forum.org/allgemein...bjectinputstream-handletable-outofmemory.html (oder hat man das mittlerweile für RMI repariert?).

Bei vielen Clients die unter Umständen unterschiedliche Wartungsstände haben bekomm ich etwas Bauchschmerzen.

Bernd

 

[Bernd Hohmann]

Und welches System empfiehlst du für den Transport komplexerer Datenstrukturen? Momentan hört sich das nach Java-Sockets an xD

Was vermutest Du worüber RMI läuft?

Ok - ich verrate es: RFC 1149 (IPoAC) mit QoS-Erweiterung aus RFC 2549.

Ansonsten würde ich mal in den DataOutputStream schauen, den kann man für grössere Blöcke prima in ein GZIP packen.

Bernd

PS: :bae:

 

[freez]

Also ich werfe mal NIO Frameworks wie Mina oder Netty (so, oder so ähnlich heist es) in den Topf. Entwicklungszeit ist minimal. Im besten Fall schubst du dein Java Objekt auf der einen Seite rein und auf der anderen plumpst es wieder raus. Allerdings kann ich wenig zur Performance in produktiven Umgebungen sagen. Im Testlabor war das jedenfalls schneller als der Zugriff über einen Servlet auf einem Tomcat. Vor allem wenn SSL mit ins Spiel kam war jeder request förmlich eine Qual über den Tomcat gegenüber Mina. Soll nicht heissen, dass Tomcat langsam ist (fürs Web reichen die par ms ja auch durchaus aus), aber wenn ich bei Tomcat 10 requests mit 10 Strings (100 Zeichen) hatte hat er 5 mal so lang gebraucht wie Mina. Ich hatte damals die Anforderung 1000 (kleine) Java Objekte / Sekunde an einen Server zu schicken. Das hat damit echt gut geklappt. Nur das Speichern der 1000 Objekte / Sekunde war dann der Knackpunkt .

Wie gesagt, nur im Testlabor und gemessen mit System.nanoTime().

PS: ich habe nicht jeden Beitrag der Diskussion gelesen. Also verzeiht, falls dieses Thema bereits abgeschmettert wurde.

 

[d3rbastl3r]

Also ich werfe mal NIO Frameworks wie Mina oder Netty (so, oder so ähnlich heist es) in den Topf. Entwicklungszeit ist minimal. Im besten Fall schubst du dein Java Objekt auf der einen Seite rein und auf der anderen plumpst es wieder raus. Allerdings kann ich wenig zur Performance in produktiven Umgebungen sagen. Im Testlabor war das jedenfalls schneller als der Zugriff über einen Servlet auf einem Tomcat. Vor allem wenn SSL mit ins Spiel kam war jeder request förmlich eine Qual über den Tomcat gegenüber Mina. Soll nicht heissen, dass Tomcat langsam ist (fürs Web reichen die par ms ja auch durchaus aus), aber wenn ich bei Tomcat 10 requests mit 10 Strings (100 Zeichen) hatte hat er 5 mal so lang gebraucht wie Mina. Ich hatte damals die Anforderung 1000 (kleine) Java Objekte / Sekunde an einen Server zu schicken. Das hat damit echt gut geklappt. Nur das Speichern der 1000 Objekte / Sekunde war dann der Knackpunkt .

Wie gesagt, nur im Testlabor und gemessen mit System.nanoTime().

PS: ich habe nicht jeden Beitrag der Diskussion gelesen. Also verzeiht, falls dieses Thema bereits abgeschmettert wurde.

Von Mina und Netty habe ich noch nie was gehört, hört sich aber vielversprechend an.
Noch jemand damit Erfahrungen gesammelt ? xD

 

[d3rbastl3r]

Natürlich funktioniert RMI ganz prima und die Performance ist auch nicht zu verachten. Ich mags nur deshalb nicht weil es im Ernstfall alle Probleme der Serialisierung mit sich bringt. Sowas da zb: http://www.java-forum.org/allgemein...bjectinputstream-handletable-outofmemory.html (oder hat man das mittlerweile für RMI repariert?).

Bei vielen Clients die unter Umständen unterschiedliche Wartungsstände haben bekomm ich etwas Bauchschmerzen.

Bernd

Hmm, habe das Thema nicht ganz verstanden (vielleicht weil ich im Thema was InputStream und OutputStrem nciht so weit drin steck) klingt aber ziemlich böse ...

Nun aber nochmal für DAU, wo wird was gespeichert und wieso (ohne mich jetzt mit ObjectInputStream verstärkt auseinander gesetzt zu haben ) bzw. ObjectInputStream.HandleTable habe ich nicht so richtig verstanden worum es geht -.-"

Nun meine Frage:
Gibt es eine Möglichkeit,
das speichern der Objekte zu
verhindern oder sie zu löschen?