1 Thread pro Client funzt zwar bei 100 Clients ist aber trotzdem nicht zu empfehlen. Steigt die Anzahl der Clients muss ggf. das ganze Design umgeworfen werden.
http://blogs.msdn.com/b/oldnewthing/arc ... 44912.aspx
Empfehlungen zum Thema Multiplayer / Netzwerk?
-
kaiserludi
- Establishment
- Beiträge: 467
- Registriert: 18.04.2002, 15:31
Re: Empfehlungen zum Thema Multiplayer / Netzwerk?
Ein gutes und halbwegs high level Framework nimmt einem solche Fragen ab.simbad hat geschrieben:Wenn du nur wenige Benutzer, 100 oder so, erwartest, kannst du einen Thread pro Benutzer machen.
Aber wenn du, sagen wir mal 10000, erwartest, würde ich mehrere connections in einem Thread verwalten und dann darin eine Art pre-processing abwickeln. Dann das ganze an ein paar Worker-Threads weiterleiten.
[...]
Auch wenn du ein Framework verwendest, solltest du über die beiden Varianten nachdenken.
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
Re: Empfehlungen zum Thema Multiplayer / Netzwerk?
Das mag wohl sein.
Ich kann mir nicht vorstellen, das alle Frameworks das gleich elegant gelöst haben. Folglich muss ich mich entweder für das eine oder andere Szenario entscheiden oder aber das Framework darauf untersuchen, wie leicht ein wechsel der Strategie möglich ist.
Genauso sollte man sich überlegen ob man mehrere Connections pro Benutzer haben wird oder nur eine. Auch das hat Einfluss auf das Gesamtdesign und die Frage ob ein Framework für den gewünschten Zweck in Frage kommt.
Da ich bis jetzt keine fremden Frameworks verwende, sondern mir alles selberbaue, weiß ich auch ganz gut, wo da der Hund begraben ist. Aber das ist eine andere Geschichte. (oder so ähnlich. In welchem Film/Serie kommt das nur vor?)
Ich kann mir nicht vorstellen, das alle Frameworks das gleich elegant gelöst haben. Folglich muss ich mich entweder für das eine oder andere Szenario entscheiden oder aber das Framework darauf untersuchen, wie leicht ein wechsel der Strategie möglich ist.
Genauso sollte man sich überlegen ob man mehrere Connections pro Benutzer haben wird oder nur eine. Auch das hat Einfluss auf das Gesamtdesign und die Frage ob ein Framework für den gewünschten Zweck in Frage kommt.
Da ich bis jetzt keine fremden Frameworks verwende, sondern mir alles selberbaue, weiß ich auch ganz gut, wo da der Hund begraben ist. Aber das ist eine andere Geschichte. (oder so ähnlich. In welchem Film/Serie kommt das nur vor?)
Re: Empfehlungen zum Thema Multiplayer / Netzwerk?
Jo Linux und fast alle anderen *nixe funktionieren anders und bieten andere Möglichkeiten.simbad hat geschrieben:Wenn du nur wenige Benutzer, 100 oder so, erwartest, kannst du einen Thread pro Benutzer machen.
Aber wenn du, sagen wir mal 10000, erwartest, würde ich mehrere connections in einem Thread verwalten und dann darin eine Art pre-processing abwickeln. Dann das ganze an ein paar Worker-Threads weiterleiten.
Unter Windows ist man bezüglich der Anzahl der Sockets pro Thread durch WaitForMultipleEvent() begrenzt.
Unter Linux hat man da mit epoll ein wenig mehr Freiheiten.
Auch wenn du ein Framework verwendest, solltest du über die beiden Varianten nachdenken.
Hier ist das gut beschrieben wie ich finde, auf Seite 2 wirds interessant.
http://www.artima.com/articles/io_design_patterns.html
Dort wird übrigens noch ein anderes Framework genannt das in der Inudstrie wohl verbreitet ist.