Multiplayer Konzept UDP

[Capt'N Coax]

Soa, bin zwar Hundemüde, aber ich kladder das trotzdem mal hier rein.

Worum gehts?

Um eine Implementierungsart eines Client/Server Modells für kleine Realtime Actiongames. Das heisst: schnelle Kommunikation ist gefragt.

Das Problem:
Es gibt zwar hunderte Tuts über Sockets und ähnliches, aber kaum sinnvolles zum Aufbau eines Client Server Systems.

So könnte man Clientanfragen im Server ja auf meherere Arten realisieren. Stichwort Threading.
Hat jemand SINNVOLLE Ratschläge wie ein solches Serversystem vernünftig zu implementieren wäre? UDP ist wohl nicht zu vermeiden, was weitere Probleme nach sich zieht, die allerdings momentan nicht so von Belang sind.

Gute Tuts die weniger die Technik als vielmehr die Architektur eines solchen Systems behandeln wären natürlich super, aber über eine Diskussion würde ich mich auch freuen :)

Habe mal testweise etwas kleines aufgesetzt, aber damit bin ich nicht wirklich zufrieden.
P.S.:

Bezieht euch wenn möglich auf Java, es geht hier auch um eine Machbarkeitsgeschichte.

Cya,
Coax

[mithrandir]

Vielleicht hilft dir das Thema "Serving multiple clients" aus "Thinking in Java" weiter:
http://www.codeguru.com/java/tij/tij0165.shtml

Ich habe das auch schon so ähnlich realisiert mit einem SocketListenerThread, der für jede eingehende Verbindung einen neuen "Arbeits"-Thread anlegt - ist eigentlich nicht so schwierig.

bye, mith

[Lrrr]

Ist zwar nicht Java related, aber vielleicht trotzdem hilfreich, an vielen Stellen eben recht allgemein über die Architektur geschrieben:

http://www.flipcode.com/network/issue01.shtml

[Capt'N Coax]

@mithrandir:

Yo, das ist lustigerweise fast genauso wie ich es zum Teil schon umgesetzt habe...
Aber sehe ich das richtig, dass pro Client ein Thread auf
Serverseite eröffnet wird?
Prinzipiell würde ich sagen, sollten 2 Threads laufen (pro C.), der eine sendet zum Client, der andere empfängt.

@Lrrr

Sehr gut, habs bis jetzt nur mal kurz überflogen, aber scheint gehaltvoll zu sein.

Bis jetzt sieht die Entwicklung bei mir folgendermaßen aus:

Der Client schickt "nur" Statuspakete (Ein Byte bis jetzt) an den Server. Dieser bearbeitet den Status und führt die erforderlichen Berechnungen durch (Kollisionsabfragen etc.). Anschliessend schickt der Server ein (im Vergleich zum Client) relativ großes Antwortpaket mit der Antwort auf den ClientStatus und der neuen Position des Clienten. Ausserdem enthalten sind natürlich Information über alle aktuellen Spieler. Der Client stellt bis jetzt NUR die Grafik dar.

Ich bin mir allerdings nicht sicher wie es Laufzeitmäßig aussieht, da ich pro Frame Serverdaten an den Client sende. Umgekehrt ist die Bandbreite eher nebensächlich, da zum Beispiel der Client nicht immer senden müsste. Wenn aktuell der Client kein expliziete Arbeit verrichtet, befindet er sich im Idle-Stazus, der eigentlich auch alle paar Frames mal versandt werden kann. Da ich davon ausgehe, das der Server an einer "dicken" Verbindung hängt, sollte dieses System bis zu einer gewissen Grenze arbeiten.

Dann is da noch die Frage des Threadens:
Threads werden doch in der Regel nach Gutdünken des Rechners abgearbeitet, ich habe also keine Ahnung wann welcher Thread wirklich bearbeitet wird. Das ist vielleicht für 2 Mann oder 8 noch okay (wären dann um die 16 Threads), bei 128 Mann dürfte das System nicht mehr so gut funktionieren...

Erfahrungswerte?

Sequenzielle Abarbeitung ist wohl kaum realisierbar?
Leider habe ich da recht wenige Vergleiche/Erfahrungen :(

[Trap]

Es gibt doch auch nonblocking Sockets, damit kann man sequentiell alle Netzwerkpakete abarbeiten.
http://bulk.fefe.de/scalable-networking.pdf ist recht interessant zu dem Thema, beschäftigt sich zwar mit Linux, lässt sich aber in großen Teilen auf Windows übertragen.

[grakaman]

Dumme Frage... Warum benutzt du nicht einfach Remoting und hostest irgendwo eine Komponente, die du über einen URI ansprichst (client activated). Da rufst du dann ganz gewöhnlich deine Methoden auf und abonnierst Ereignisse.

MfG

[Capt'N Coax]

Original geschrieben von grakaman
Dumme Frage... Warum benutzt du nicht einfach Remoting und hostest irgendwo eine Komponente, die du über einen URI ansprichst (client activated). Da rufst du dann ganz gewöhnlich deine Methoden auf und abonnierst Ereignisse.

MfG

Sorry, das musst du mir jetzt näher erklären.
Komponente? Was und wie remoten? Ereignisse abonnieren?

Kann es sein, das du hier einen gänzlich anderen Ansatz verfolgst? :)

Ich weiß jetzt ehrlich gesagt nicht wo ich das unterbringen soll.

[Capt'N Coax]

So, vielleicht knobelt ja einer mit. :)

Bevor ich mich jetzt wieder in die große Proggerei stürze, mal meine gesammelten Infos die ich mir grade herausgekramt habe.

Nochmal zur Erinnerung:
Es geht um UDP und Realtime Datenübertragung, also kein "Vier gewinnt" :).

Zu UDP habe ich folgendes herausgefunden (Ich werde jetzt wohl doch etwas Implemetierungsspezifischer):

Es gibt IMO 3 sinnvolle Möglichkeiten per Java so ein Client/server - System aufzusetzen:

1. Man(n) macht für jeden Clienten einen extra Socket per Thread auf, der allerdings auch einen extra Port benötigt. Und zwar deswegen, weil UDP verbindungslos ist. Per TCP ist dieser Sachverhalt einfacher: Ich erstelle nach dem Connect einen neuen Thread der sich um die Verbindung zwischen Server/Client kümmert. Da Udp nur einfache Datagramms sendet und keine Verbindung aufbaut, muss ich hier über einen extra Port arbeiten.
Nachteile:
Schlecht, weil ich je nach Clients mehrere Ports aufmachen muss, was erstens nicht gängig und zweitens nicht praktikabel ist (Stichwort Router/NAT).

2. Man arbeitet mit einem Thread der sich um ALLE eingehenden Anfragen kümmert. Kommt eine Anfrage, wird diese von einem extra - Thread bearbeitet. So kann man die Arbeit aufteilen, aber nicht jeder Client kommuniziert über seinen eigenen ServerThread.
Nachteile:
Bleibt zu sehen wie gut der Server mehrere Anfragen bewältigt, da der Flaschenhals hier receive im MainThread sein dürfte.

3. Ich habe läuten hören, das es ein JavaPacket java.nio.* gibt, welches non-blocking Kommunikation unterstützt. Damit wird Sequenziell wieder interessanter. Methode 2 könnte man sozusagen auch als "Pseudo nonBlockin'" bezeichnen, das nur mal so b.t.w.

Liege ich mit den 3 Möglichkeiten falsch oder wie seht ihr das?

[grakaman]

Original geschrieben von Capt'N Coax
Sorry, das musst du mir jetzt näher erklären.
Komponente? Was und wie remoten? Ereignisse abonnieren?

Kann es sein, das du hier einen gänzlich anderen Ansatz verfolgst? :)

Ich weiß jetzt ehrlich gesagt nicht wo ich das unterbringen soll.

Du hast du meines Wissens 3 Möglichkeiten.

Server activated
- Single Call (jeder aufruf erzeugt ein neues Objekt auf dem Server)
- Singleton (eine Instanz versorgt alle Aufrufe)

Client activated

Dabei brauchst du natürlich auf dem Client zumindest eine Interface Definition für deine Remote Komponente. Und die Klassen müssen, zumindest bei .NET Remoting, entweder von MarshallByRef oder MarshallByValue abgeleitet sein. Ersteres macht immer Round Trips zum Server, ist also statefull und letzeres erstellt eine Kopie des Remote Objektes in dem anderen Prozess. Der Rest kann einfach über eine Config Datei eingestellt werden (Port, Aktivierung, URI). Hier mal ein einfaches Bsp. für ein Server activated Single Call. Vielleicht kannst du das irgendwie adaptieren:

http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=62

MfG

Ps. Ich halte es für ziemlich unnötig, bei deinem Problem mit reinen Sockets rumzuhantieren. Sowas macht man, wenn man es muss, z.B. bei Email etc.

[Lrrr]

@Grakaman:

Ich glaube das Remoting des .NET Frameworks mit Deinem C# Beispiel ist wohl eher ungeeignet für die Zwecke, die Capt'N Coax hier verfolgt. Außerdem verwendet es TCP als Protokoll, ich bezweifle, dass es mit UDP funktioniert, berichtige mich, falls ich falsch liege. Das ganze klingt nicht sehr performant.

[grakaman]

Original geschrieben von Lrrr
@Grakaman:

Ich glaube das Remoting des .NET Frameworks mit Deinem C# Beispiel ist wohl eher ungeeignet für die Zwecke, die Capt'N Coax hier verfolgt. Außerdem verwendet es TCP als Protokoll, ich bezweifle, dass es mit UDP funktioniert, berichtige mich, falls ich falsch liege. Das ganze klingt nicht sehr performant.

Du kannst alles mögliche verwenden, da du selbst deine Channels schreiben kannst. TCP/HTTP ist eben build in. Und wozu brauchst du bei dieser Aufgabe überhaupt UDP?

[Capt'N Coax]

Tcp hat ein paar entscheidenen Nachteile was Geschwindigkeit angeht:

Handshaking/Flowcontrol/Fehlerbehebung etc. kosten Zeit.
Es hat für eine Realtime Umgebung keinen Sinn, je nach Serverseitigem Empfang zu warten bis dieser sich seine Pakete gerade gekramt hat. In der Zeit passiert nämlich nix. Also auch wenn ein fehlerfreies Paket ankommt, wird erst gewartet bis die komplette Information vorliegt. Neue Infos werden so also nicht direkt bearbeitet.

Der Nutzen von UDP ist bis jetzt wenigstens im Videostreaming/Gaming ersichtlich gewesen, ich denke mal die Leute wissen was sie tun. Hoffe ich :).

Wenn Argumente FÜR eine Benutzung von TCP vorliegen, bin ich gerne Bereit das zu testen. Ich behaupte aber mal das ein UDP Server hier etwas schwerer zu implementieren ist (und auch etwas anders :) ). Vielleicht werde ich mal beides versuchen und messen wie die Verbindung da aussieht.

@grakaman

Hab mir das Beispiel mal angeschaut. Ich habe zwar .Net+C# druff, allerdings ist mir das jetzt zu viel Umdenken. Und ich weiß auch nicht was bei diesem Ansatz herauskommen wird. Ich leg das erst mal in den Hinterkopf, trotzdem THX!

Und naja, Sockets unter Java sind ja nun wirklich nicht umständlich gelöst ;).

Ich denke ich probiere mal die 2. Möglichkeit aus (aus meiner Erklärung), und sehe wie weit ich komme.

[ScottManDeath]

Ich habe mit .NET remoting eine über TCP von einenm PC Videodaten an einen anderen geschoben. Framegrösse ca 6KByte, Framerate ca 10, also deutlich zu langsam. Werde das ganze auf eine Mischung aus Remoting und Sockets umstellen.

[Xmas]

Capt'N Coax, welche Art von Spiel soll das werden. Sprich, soll der Gamestate komplett vom Server berechnet werden? Wie oft? Senden die Clients einfach wild ihre States (z.B. einmal pro Grafikframe)? Soll jeder ankommende Client-State eine Neuberechnung im Server auslösen? Oder wartet der Server auf alle Clients, bis eine Neuberechnung stattfindet?

Mein Vorschlag:
Ich kenne die Sockets in Java nicht, aber eigentlich brauchst du nur einen einzigen Socket. Bei Empfang eines Datagramms spawnst du einen neuen Thread, der das Datagramm übernimmt und z.B. anhand der Absenderadresse an eine bestimmte Position in der "Client-State-Liste" auf dem Server einfügt. Dieses Einfügen muss synchronisiert sein, denn auf dem Server läuft gleichzeitig noch ein Thread, der Timergesteuert alle X ms die Client-State-Liste ausliest und daraus einen neuen Gamestate berechnet, der dann sofort über den Socket an alle Clients geschickt wird. Ob Ein Sender-Thread wirklich notwendig ist, hängt davon ab ob der Server viel Zeit zur Berechnung braucht. Mehrere Sender-Threads sind unnötig, da sie sich eh alle blockieren. Ist seit der letzten Berechnung kein neuer Client-State eingetroffen, musst du unter Umständen eine Vorhersage einbauen, oder schlicht den alten State weiterverwenden.

[Capt'N Coax]

Hoi Xmas,

Der Gamestate wird komplett vom Server übernommen. Ich möchte so weit es geht alle Logik Sachen über den Server laufen lassen (Cheatsicherheit etc.). Das KANN serverseitig ziemlich aufwendig werden, von daher möchte ich gerne mit einem Sicherheitspuffer arbeiten.

Client:
Ein Client versucht nach jedem Frame einfach ein Datagramm abzusenden, wenn er mit seinen Berechnungen durch ist (sprich: Wenn alle Usereingaben abgefangen wurden). Da der Client NUR Grafik ausgibt und SteurungSTATES annimmt (Also im Sinne von "gehe Rechts", "Feuer" etc.) fallen die Pakete hier sehr klein aus.

Server:
Der Server lauscht ja prinzipiell zu allererst auf eine generelle Anfrage (Nach Neustart). Kommt eine Anfrage, und handelt es sich um eine ConnectAnfrage des Clients, muss etwas geschehen:

Und hier wirds jetzt lustig:

Wenn ich dich richtig verstehe, sollte das nun so laufen:

-Ein thread muss schonmal gestartet sein, der auf Client-Connect Anfragen horcht, um überhaupt erst einen neuen Thread zu eröffnen.

-Kommt ein Connect an, wird ein neuer Thread eröffnet, dem ich (feierlich) die Aufgabe übergebe, mit dem State-Paket irgendetwas anzufangen (Je nach State). Dieser Thread greift also auf meine LevelDaten zu (synchronized) und ändert dort den PlayerState anhand durch den Level vorgegebener Daten (Kollision). Ist dieser Thread mit seiner Arbeit fertig, dann...Close?

-In der Zeit in der dieser Thread arbeitet, kann natürlich schon der nächste Connect reinschneien, und das Spiel beginnt von vorne -> Wir haben hier eine gute Verteilung.
-Jetzt kann ich nach einer gewissen Zeit ein Antwortpaket aus den (upgedateten) Leveldaten verfassen, was sich gut anhört, aber hier gibt es ein Problem aus meiner Sicht:

Wer erstellt das antwortPaket? Der "lauschende" Thread? Das ist IMO ungünstig, da ClientAnfragen unnötig aufgehalten werden könnten.

Also nehmen wir testweise einen dritten Thread dazu, der nach einer gewissen Zeit die Leveldaten packt und sozusagen einen Broadcast an alle Clienten veranstaltet. Wenn wir hierfür einen Thread haben, können wir eventuell sogar einfach Datagrams rauspumpen , unterbrochen wird er ja nur durch die Schreibzugriffe der temp. (?) Threads der ClientAnfragen.

Eines ist auf jeden Fall klar: Ich habe mit UDP nur EINEN Thread frei, der lauschen kann (Ein Socket mit gleichem Port zur gleichen Zeit). Deswegen muss ich diesen so schnell wie möglich wieder freimachen. Also delegieren wir Rechenprozesse und Broadcast an Unterthreads, um dem Client wenigstens eine gute Antwortzeit "vorgaukeln" zu können.

Ich bin gerade recht verbissen am überlegen, wo hier die Engpässe liegen könnten. Ich bin mir nicht sicher, aber ich denke das auf einem Port sowieso nur ein Socket die Ein/Ausgabe übernehmen kann (Ich habs jetzt gerade nicht im Kopf), also wären hunderte Threads (Für hunderte Player) eh Schwachsinn, villeicht scheuer ich aber gerade auch total an der Technik vorbei, ich hab allerdings diesbezüglich mit Fehlermeldungen zu kämpfen gehabt :(. Muss ich nochmal nachschauen.

Wichtig ist, das alle Clients so schnell wie möglich an die Statuspakete vom Server kommen, da der SpielStatus sich ja mit jedem Frame ändert. Stelle dir einfach Quake vor, da muss ich immer auf dem laufenden bleiben. Ich hab zwar nicht vor Quake neuzuerfinden, aber das System ist das Selbe. Vielleicht weniger byteLastig für die Übertragung ;).

Clientprediction ist ein Stichwort, das ich aber erstmal weglasse. Das betrifft eigentlich auch nicht direkt den Server.

Ich wollte noch irgendwas schreiben...
Ach ja, die Frage mit dem Datagram- Thread:
Wäre nett, wenn du mir kurz erläuterst wie du diesen Prozess im Kleinen umsetzen würdest.

-> Datagramm kommt -> Leveldaten laden-> Logik berechnen -> neue PlayerDaten speichern -> Thread closen oder Idlen?

Einen neuen Thread zu erstellen bei jeder anfrage ist, glaube ich gelesen zu haben, nicht gut. Besser wäre ein Thread Pool, dann hätten wir allerdings wieder permanente Threads, die sich unter Umständen aufhalten.

Muss ich beim Lesen eigentlich auch synchronizieren?

Noch ein Problem:
Wenn PlayerAktionen geschehen, werden ja auch weitere Objekte (Projektile) dem Level hinzugefügt. Eventuell könnte es da Probleme mit der Reihenfolge geben, wenn ich mit Threads arbeite. Nur zur anregung :)

Ich hätte mir gerne mehr Mühe mit dem Verfassen gegeben, aber ich muss ins Fitnessstudio fahren. Die Methode mit dem Daumen im Mund und kräftig pusten funktioniert nämlich bei mir nicht ;).

Hoffentlich habe ich euch nicht mehr verwirrt mit dem Text, bis gleich oder so,

Coax

[Xmas]

Also, ich stelle mir das folgendermaßen vor (wobei ich anmerken muss dass ich selbst nur selten threaded programmiere, also eher auf die Theorie aufbaue):
Auf dem Server laufen

- ein Listener-Thread, der an einem UDP-Socket auf Datagramme wartet. Kommt ein Datagramm an, wird dieses sofort an einen Datagramm-Handler-Thread weitergereicht. Mehr muss dieser Thread nicht tun.

- ein Listener-Thread, der an einem TCP-Socket auf Game-Connect-Anfragen wartet. Ob dieser Thread nun Aufgaben delegiert oder alles selber macht, ist ziemlich egal, da Connect-Anfragen selten und nicht zeitkritisch sind. Hier muss das Anlegen/Ausfüllen von Datenstrukturen für einen weiteren Spieler ausgelöst werden.

- mehrere Datagramm-Handler-Threads (die wohl wirklich besser alle am leben bleiben und idlen). Wieviele, kommt auf die Natur der Client-Daten an. Wenn jeder neue Client-State den alten überflüssig macht, dann brauchst du nur genauso viele Threads wie du Clients hast, ansonsten mehr.
Diese Threads verarbeiten die Datagramme und fügen die Client-States in eine Client-State-Liste ein. Dies muss synchronisiert sein.

- ein Gamestate-Berechner-Thread, der die Client-State-Liste regelmäßig ausliest (wenn gerade ein Datagramm-Handler-Thread schreibt, muss natürlich gewartet werden) und daraus einen neuen Gamestate berechnet. Ist dieser Gamestate fertig, wird er an den Sender-Thread übergeben.

- ein Sender-Thread, der den Gamestate sequenziell an alle Clients via den UDP-Socket übermittelt, und danach idelt.

Du musst dir vor allem genau überlegen was passieren soll, wenn ein Verarbeiter-Thread zu langsam ist, wenn ein Datagramm verloren geht oder fehlerhaft ist, und ob die Verarbeitung Ereignis- oder Timer-gesteuert sein soll.

[Demirug]

Lasst das mit den vielen Threads das ist nicht gut.

Ich hatte auch mal einen Server der für jeden Client einen eigenen Thread hatte. Hat sehr schlecht skaliert das ganze. Daraufhin habe ich alles was mit der Netzwerkkommunikation zu tun hat in nur einen Thread gepackt. Läuft viel besser.

[Capt'N Coax]

@Xmas

Jupp, das hört sich so an wie ich mir das auch vorgestellt habe. Paketloss und Verbindungsprobleme unter UDP sind allgemein DAS Problem an der Geschichte. Unter Umständen wird man auch ClientPrediction einbauen müssen, die man mit dem Server abgleicht. Bin da ja auch noch nicht so firm :)

Eine Anmerkung noch:
ConnectAnfragen werden (so weit ich das bis jetzt habe) ja im selben ClientPaket gesendet. Das heißt das ein Thread ALLE Anfragen behandeln muss, und dann erst nach Status sortiert/delegiert.

@Demirug
Hatte mich schon gefragt wann diese Aussage kommt und mir das ganze Konzept versaut ;).

Wichtig ist erstmal, dass ich ein paar Alternativen habe. So werde ich jetzt beide Versionen mal testen und an meine Anforderungen ausrichten, darauf läuft es eh hinaus.

Darf man fragen, in welchem Zusammenhang du diesen Server genutzt hast?
Ist die schlechte Skalierung auf die gegenseitige Beeinflussung der Threads zurückzuführen oder allgemein auf Resourcenhunger der Threads?
Reines ClientServer Modell, bzw. muss ich deiner Erfahrung nach von vorneherein auf etwas achtgeben, damit mir mein Code später nicht das Konzept über den Schädel zieht?

[Demirug]

Original geschrieben von Capt'N Coax
Darf man fragen, in welchem Zusammenhang du diesen Server genutzt hast?

Sicher. Das ganze ist ein Server (eigentlich sind es immer mindestens zwei in einer Hot-Stand-By Konfiguration)welcher mehrere PCs mit Echtzeitdaten aus einer Industrieanlage versorgt.

Ist die schlechte Skalierung auf die gegenseitige Beeinflussung der Threads zurückzuführen oder allgemein auf Resourcenhunger der Threads?

Die einzelnen Threads waren weitgehend durch FIFOs entkoppelt das war also nicht dazu problem. Das wechseln von Thread zu Thread verbraucht einfach eine Menge CPU-Leistung.

Reines ClientServer Modell, bzw. muss ich deiner Erfahrung nach von vorneherein auf etwas achtgeben, damit mir mein Code später nicht das Konzept über den Schädel zieht?

Im Server sollte man versuchen dynamische Speicheranforderungen wärend des Betreibs auf 0 zu drücken. Nachdem wir das gemacht haben laufen die Server problemloss bei minimaler CPU belastung und auch ewig.

[ScottManDeath]

Original geschrieben von Demirug
Im Server sollte man versuchen dynamische Speicheranforderungen wärend des Betreibs auf 0 zu drücken. Nachdem wir das gemacht haben laufen die Server problemloss bei minimaler CPU belastung und auch ewig.


Wie sieht das bei GC Systemen wie Java oder .NET aus? Da passiert es unter Umständen doch das man einige Objekte dynamisch anlegen muss?

[Trap]

Ein GC verbietet Echtzeitfähigkeit (=garantierte Antwortzeiten) nicht. Die Sprache muss allerdings speziell dafür entwickelt sein.
Eine primitive Lösung wäre es in den Echtzeitteilen den GC abzuschalten und alle Objekte vorher anzulegen. Man kann die dann noch benötigten Objekte auf dem Stack anlegen, was sehr schnell ist und auch fest kalkulierbare Zeit benötigt.

[Demirug]

Original geschrieben von ScottManDeath
Wie sieht das bei GC Systemen wie Java oder .NET aus? Da passiert es unter Umständen doch das man einige Objekte dynamisch anlegen muss?

Die einzelnen GCs die jeweils bei Java zum Einsatz kommen kenne ich jetzt nicht so im Detail.

Der .Net GC kommt damit aber recht gut zurecht da er ja den Heap automatisch defragmentiert. Gerade die Fragmentierung des C++ Heaps war das Hauptproblem bei der Serveranwendung. Diese führte dazu das die benötugte Speichermenge dazu neigte zu steigen und die Zeit für eine Speicheranforderung ebenfalls ständig zunahm.

Trotzdem sollte man es sich gerade bei grösseren Objekten überlegen ob man diese wirklich ständig neu anlegen muss.

[Capt'N Coax]

Jetzt nur mal so ein Gedanke:

Speichermanagement in Java ist durch dessen Natur ja angeblich effektiver als in unmanaged Sprachen wie C++ zum Beispiel. Ich meine gelesen zu haben, dass realloziierung generell einen Geschwindigkeitseinbruch verursacht (Da kann man wohl auch sicher sein).
Sollte Java also in diesem Bereich nicht sogar besser geeignet sein?

Ist aber auch möglich dass ich gerade Quatsch schreibe, Informationen aus 8. Hand halt ;).

[grakaman]

Original geschrieben von Capt'N Coax
Jetzt nur mal so ein Gedanke:

Speichermanagement in Java ist durch dessen Natur ja angeblich effektiver als in unmanaged Sprachen wie C++ zum Beispiel. Ich meine gelesen zu haben, dass realloziierung generell einen Geschwindigkeitseinbruch verursacht (Da kann man wohl auch sicher sein).
Sollte Java also in diesem Bereich nicht sogar besser geeignet sein?

Ist aber auch möglich dass ich gerade Quatsch schreibe, Informationen aus 8. Hand halt ;).

Ich kann dem nicht recht folgen. Java/.NET muss ja ebenfalls realloziieren. Du sprichst hier aber einen Punkt an, den man mit entsprechenden Enterprise Services wie Object Pooling/JIT optimieren kann, um besser zu skalieren.

MfG

[Capt'N Coax]

Unter anderem haben mich solche Artikel wo zu oben genannter Aussage veranlasst:

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

Ab Punkt 2 fallen dort ein paar interessante Argumente.
Das ist aber nicht die einzige Seite die dergleichen beschreibt, allerdings krame ich jetzt nicht nach Links :)

N8