qtforum.de

Hallo,

ich bin gerade am überlegen, wie ich am geschicktesten meinen Server Programmiere:
Er soll auf viele Verbindungen und Performance ausgelegt sein.
Für jede Verbindung einen Thread zu erstellen, halte ich für nicht schlau. ( Wenn theoretisch 20000 Clients mit dem Server verbunden sind hätte er 20000 threads und dieser Gedanke gefällt mir nicht ) aber eine andere Idee fällt mir gerade nicht ein, wie machen das die Profis unter euch ?

Mfg

Hallo!

Ich würde mich nicht als Profi bezeichnen und bin deshalb froh, wenn ich berichtigt werde.
Ich glaube, QT macht das Ganze automatisch.
Du musst die Verbindungen nur annehmen und die entsprechenden Signale benutzen. Ich habe meinen Server komplett ohne die QThread-Klasse
geschrieben.

Wie es da mit der Performance aussieht, weiß ich nicht. Ich musste bisher nicht so viele Clients verwalten.

Ich habe nun einen kleinen Server mit hilfe von diesem Tutorial programmiert: VoidRealms
Dazu habe ich noch ein paar Fragen:

Der Thread ist nur für den Task aber nicht für das Socket , aber da Woodfighter meint dass QT das für das Socket ja automatisch macht können sich mehrere Clients mit dem Server verbinden?

Wenn der Client was an den Server sendet führt er etwas aus und schickt eine Antwort, was auch gelingt, doch was ist, wenn zb im Server ein Timer abläuft, der eine Nachricht nur an bestimmten Clients rausschicken soll ? ( Angenommen der Client hat sich mit einem Usernamen beim Server authentifiziert )
Ich weis nur nicht wie ich das programmieren soll, eventuell den Usernamen und der dazugehörende socketdescriptor in einer Tabelle speichern, doch wie greife ich dann auf das richtige socket zu ?

Das war nun ziemlich viel aber ich hoffe jemand kann mir weiter helfen, sitze nun schon ne weile vorm Bildschirm und komm einfach nicht weiter.

Ich würde sagen hier ist genau da was du suchst: http://doc.trolltech.com/4.7/network-th ... erver.html

in diesem Beispiel wird für jedes Socket ein neuer Thread erstellt, aber genau sowas wollte ich eigentlich nicht machen, trozdem thx.

Ich würde mir zusätzlich noch das Beispiel Network-Chat-Example anschauen. Wie Du in der server.cpp erkennen kannst, wird pro Client, der sich mit dem Server verbindet, ein Client-Objekt angelegt, in dem Du dann mit dem Client kommunizieren kannst (auf Signals reagieren, in Socket-Verbindung schreiben). Nach der Implementierung würde ich testen, wie viele Clients Du verarbeiten/bedienen kannst. Es hängt sicherlich auch von den Arbeiten ab, die ausgeführt werden, wenn der Client Daten bzw. Ergebnisse anfordert.

ich bin gerade am überlegen, wie ich am geschicktesten meinen Server Programmiere:
Er soll auf viele Verbindungen und Performance ausgelegt sein.

Um das entscheiden zu koennen, wirst um entsprechende Literatur ned drumherumkommen ...
und wir werdens fuer dich auch nich tun koennen ...

Du solltest dich dringend in folgende Themen einarbeiten:
- wie "synchron" sind prozesse mit einem Thread wirklich , Signal-Konzept (nicht verwechseln mit dem Signal-Slot mechanismus von QT)
- Assynchrone BS-Objecte (FileIO, Pipes, Sockets) und synchrone Programmierung (ein Prozess ein Thread)
- Multithreading vs. Multiprozessing
- Limits (vom Betriebssystem)

Das ganze ist ziemlich Aufgaben und auch Systemabhaengig. Unter Linux wuerd ich anders vorgehen als unter windows z.b.

Wenn theoretisch 20000 Clients mit dem Server verbunden sind

Wenn das ansatzweisse realistisch ist, wirst soweiso ziemlich weit in die Trickkiste greifen muessen ......

z.b wenn fuer jeden socket nen zeiger speicherst hasst schon mal 80kbyte im RAM, verwaltungsinfos noch ned bei.
wenn das ganze in ne map haengst / B-Baum sind schon mal paar Mbyte im Ram weg .... usw so setzt sich das fort.
die frage mit socket zu trhead wird sich eruebrigen, da windows zwar normal 32k sockets kann, rein theorethisch, aber definitiv keine 32k threads ^^
Allein der Stack der fuern thread angelegt wird, wuerde dir deinen speicher sprengen ^^
32k prozesse wirst auf deinem system dementsprechend auch nicht unterbringen ....

Wie gesagt ist schon abwaegungsfrage .... normal nimmt man bei sowas was in die richtung geht Mix .... aus (preforking) multiprozess / threaded / und assynchrone Objecte ... und versucht intelligent ressourcen zu verteilen.

Hasst du wirklich 20K clients, die staendig wirklich dinge tun, wuerde man normal schon ueber clustering(mehrere rechner einbeziehen) nachdenken ....

Ciao ...

so, hab mich ein wenig übers clustering informiert und wenn ich das richtig verstanden habe, muss ich da beim Programmieren meines Servers nichts berücksichtigen, da das dann mein Betriebssystem übernimmt oder ?
Als alternative hätte ich das so programmiert: Ich hätte im Server ein connections Limit integriert und wenn das erreicht ist, sendet der Server ein "voll" an den Client der dann aus einer IP-Liste sich den nächsten Server raussucht und versucht sich mit dem zu Verbinden. Nur jeder Server muss auf die selbe SQL Datenbank zugreiffen, was die Anzahl an gleichzeitigen Connections auf die Datenbank erhöht.

z.b wenn fuer jeden socket nen zeiger speicherst hasst schon mal 80kbyte im RAM, verwaltungsinfos noch ned bei.
wenn das ganze in ne map haengst / B-Baum sind schon mal paar Mbyte im Ram weg .... usw so setzt sich das fort.

Da sich der Server die Verbindung merken soll, muss ich irgendwo den Pointer auf das Socket und den Usernamen in Verbindung bringen, die einzige Alternative würde mir jetzt einfallen, die Zuordnung auf eine SQL-lite Tabelle auszulagern, was aber, denke ich mal, langsamer ist ( Ich denke dass ich die Daten nicht allzu oft brauchen werde: ein Zugriff für eine neue Verbindung, einen fürs löschen,selten wenn mal Daten an einen speziellen Client gesendet werden soll und fürs ca alle 15min ein Alive ping zu senden um zu schauen ob der Client noch da ist ).

Generell, bevor ich anfangen wuerde mich da mit implementationsdetails zu befassen, wuerd ich das "Protokoll" noch mal unter die lupe nehmen ....

20K User staendig an einen rechner ist recht utopisch.
Das du "connections" "User" "Prozesse" "logins" etc. wiedererkennen musst, bedingt aber nicht zwangslaeufig ein verbindungsorientiertes protokoll ...
Such mal im Inet literatur ueber sessionhandling und http(verbindungsloses Protokoll). Da bekommst sicher nen gefuehl, wie man mit sowas umgehen kann ....

dann analsysiere dein Protokollanforderungen.
z.b. wenn bei der Kommunikation pausen drinne sind, die 10 mal oder mehr so gross sind wie mit nem effizienten Algo fuers handshaking(Verbindungsaufbau + user wiedererkennung), dann wuerd ich dir nen verbindungsloses protokoll empfehlen.
Wird dir viel nerven und wahrscheinlich auch HW ersparen.
15 min pausen sind definitiv nen grund um die verbinndung abzubauen ^^ in so einem szenario ^^
und auch mit verbindungslosen protokollen gehen alive pings.

Als alternative hätte ich das so programmiert: Ich hätte im Server ein connections Limit integriert und wenn das erreicht ist, sendet der Server ein "voll" an den Client der dann aus einer IP-Liste sich den nächsten Server raussucht und versucht sich mit dem zu Verbinden. Nur jeder Server muss auf die selbe SQL Datenbank zugreiffen, was die Anzahl an gleichzeitigen Connections auf die Datenbank erhöht.

Ja so aehnlich funktioniert es, nur nicht ganz so naiv implementiert ....
normal baut man bei sowas nen login server, wo sich die user authentifizieren, und dann an nen "live" server weitergereicht. diese vermittlung ist meist noch ein bissi intellligenter als nur "der eine server ist voll nu der naechste" .... aber so in etwa. Ob man SQL als backend fuer die daten nimmt iss noch ne andere Frage ... meist gehen die anforderungen mehr auf performance denn transaktionssicherheit und datenitegritaet -> NoSQL Lösung.

Aber ueberleg dir das nochmal, ich glaub ned das du soviel tranfer hasst, das sich das lohnt. Schau lieber ob das mit dem verbindungslosen Protokoll hinbekommst ....

Ciao ...

Darf ich fragen, was der Server für eine Aufgabe hat bzw. was es für ein Projekt ist, wo 20.000 Clients gleichzeitig auf einen Server zugreifen?

Markus hat geschrieben:Darf ich fragen, was der Server für eine Aufgabe hat bzw. was es für ein Projekt ist, wo 20.000 Clients gleichzeitig auf einen Server zugreifen?

Es wird ein Tabellen basiertes Spiel ( ähnlich wie travian nur ausgefeilter, und ein besseres Konzept )
Natürlich werden es nicht so viele Clients sein, nur will ich meinen Server optimal programmieren und ihn nicht nur auf 10 Clients auslegen. Einmal richtig programmiert spart viel Zeit.

@RHBaum:
Für mich wäre das Verbindungslose Protokoll besser geeignet, allerdings wird auch ein Chat laufen und da ist das Verbindungslose Protokoll weniger gut geeignet.

allerdings wird auch ein Chat laufen und da ist das Verbindungslose Protokoll weniger gut geeignet

Definitiv nicht ^^
Verbindsorientiert heisst du nutzt TCP/IP und laesst die Verbindung die ganze zeit stehen ....
fuern chat definitiv zu ressourcenfressend. chats sind eher nen gutes Bespiel fuer verbindungslosse Protokolle ^^

Besser:
- wenn der client was will, verbindung aufbauen, nachricht schicken, verbindung abbauen ....
- regelmaessig neue "nachrichten" abfragen ..... dazu verbinden, nachricht abholen, verbindung abbauen ... was auch gleichzeitig als "alive" Mechanismus dienen kann

Das vieeeeeeel ressourcenschonender fuer den Server ... und client.

Verbindungslos auf Transportebene heisst nicht, dass der User sich nicht verbunden fuehlt ^^
Mann kann da genau so an und abmelden einbauen .... usw. -> siehe sessionmanagment .

Abegesehen davon, dass es dafuer nicht nur fertige Protokolle, und unmengen an clients gibt (ja ich weiss, du willst es selber machen ...)
Du koenntest aber z.b. nen "Jabber" server bei dir aufsetzen und dein Programm um die Client funktionen erweitern ....

Ciao ...

hmmmm ok, ich war der Meinung, dass wenn ich alle 2 Sekunden eine Verbindung aufbaue ( ich benutze ein QSSLSocket da ist ja noch mehr Aufwand dabei eine neue Verbindung herzustellen ), Daten anfordere und die Verbindung wieder trenne mehr Ressourcen frisst als wenn ich die Verbindung halte. Experimentiere gerade mit beiden Varianten.

hmmmm ok, ich war der Meinung, dass wenn ich alle 2 Sekunden eine Verbindung aufbaue

Naja, das ne Gradwanderung zwischen Rechenleistung(als Ressource) vs. anderen statischen ressourcen (Hauptspeicher, Handles etc).

Wobei du bei tcp/ip +ssl den kompletten Handschake bei verbindungsaufbau durchlaeufst ... das auch nen killer ^^

Aber bei so "speziellen" Anforderungen wirst wohl um low level nicht drumherum kommen .... auch wenn QSsl so bequem ist.

DU kannst tcp/ip auch unverschluesselt(raw) nutzen, und die daten selber verschuesseln und verschicken, dann ersparst Dir den handshake mittendrin, was in deinem falle 99% der kommuniaktion waeren ^^
die keys kannst fuer den verlauf einer (von dir definierten) "session" schon speichern
dazu muesstest dich aber scho bissi in kryptographie einarbeiten ....

aller 2 sek mal nen "Ping" (Verbindung auf und abbau) ueber TCP/IP ist durchaus ok,
aber aller 2 sek nen kompletter ssl Aufbau (handshake) ist schon ne ganz andere Liga ! ^^

generell kannst noch mehr optimieren wenn von tcp weggehst und udp verwendest ... das musst eh selber verschluesseln ^^

Extreme Anforderungen erzeugen extremen Aufwand ^^

Ciao ...

ok, dass ich die Daten selber verschlüssele finde ich eigentlich die beste lösung, dafür bietet qt ja auch entsprechende libs, nur wo soll ich denn den Key zum ver und entschlüsseln auf dem Client ablegen ? In eine Variable Speichern ist zu unsicher...