Hallo,
ich möchte einen Chat Server schreiben (später sollen auch noch andere Daten übertragen werden).
Dazu habe ich einen QTcpServer vererbt, welcher QThreads erstellt (falls ein Client - im Moment ein leicht modifiziertes Client aus den Network examples - verbinden möchte) die wiederum eine Klasse von mir erstellen (Verteiler).
Die Verteiler sollen dann einen QTcpSocket erstellen.
Das ganze funktioniert auch so weit dass ich auf Daten vom Client empfangen kann und darauf automatisch antworten. Nun möchte ich aber dass nicht nur auf die Daten vom Client gewartet wird (im Moment durch QTcpSockie.readyRead()) sondern auch Daten von einem Stapel (diejenigen Daten die die anderen Clients gesendet haben) genommen und an den Client gesendet werden. Für den Stapel will ich ein QMutex/QMutexLocker verwenden, Problem ist:
Wie warte ich einerseits auf Daten vom Client, aber anderseits auf Daten von dem Stapel? QWaitConditions sieht irgendwie wie das aus was ich brauche, allerdings bin ich mir nicht sicher, und weiss auch nicht wie ich die Klasse einsetzen kann.
Ich hoffe es war verständlich und ihr könnt mir weiterhelfen. Nebenbei wüsste ich noch gerne ob die Vorgehensweise (für jede Verbindung ein Thread) sinnvoll ist oder ob ich das lieber anders machen soll.
Chat-Server
-
Christian81
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Re: Chat-Server
Keine Ahnung ob ich alles verstanden habe - hört sich irgendwie konfus an.
Aber: wo genau liegt das Problem? Wenn Daten vom Socket kommen dann gibts das readyRead() - Signal, wenn Du Daten senden willst, gibst Du deinem Thread die Daten in eine Queue (gesichert mit einem Mutex) und sendest an den Thread danach ein Signal dass es neue Daten gibt. Im zugehörigen Slot sendest Du die Daten an den Socket und fertig.
Aber: wo genau liegt das Problem? Wenn Daten vom Socket kommen dann gibts das readyRead() - Signal, wenn Du Daten senden willst, gibst Du deinem Thread die Daten in eine Queue (gesichert mit einem Mutex) und sendest an den Thread danach ein Signal dass es neue Daten gibt. Im zugehörigen Slot sendest Du die Daten an den Socket und fertig.
MfG Christian
'Funktioniert nicht' ist keine Fehlerbeschreibung
'Funktioniert nicht' ist keine Fehlerbeschreibung
Re: Chat-Server
Falls kein readyRead() Signal kommt blockiert mein Thread dank des waitForReadRead(-1) - ausser ich verstehe etwas falsch. Eine Idee die ich schon hatte ist dass ich waitForReadyRead(10) verwende und dann immer nach 10ms überprüfe ob ich auch Daten schreiben muss. Aber irgendwie gefällt mir diese Lösung nicht so gut.Christian81 hat geschrieben:Keine Ahnung ob ich alles verstanden habe - hört sich irgendwie konfus an.
Aber: wo genau liegt das Problem? Wenn Daten vom Socket kommen dann gibts das readyRead() - Signal, wenn Du Daten senden willst, gibst Du deinem Thread die Daten in eine Queue (gesichert mit einem Mutex) und sendest an den Thread danach ein Signal dass es neue Daten gibt. Im zugehörigen Slot sendest Du die Daten an den Socket und fertig.
Deswegen suche ich eben irgendwie eine Wait-Condition die nicht nur gelöst wird falls Daten am QTcpSocket anliegen sondern irgendwas in meinem Stapel (gesichert über die QMutex) ist (auch über ein Signal).
-
Christian81
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Re: Chat-Server
Warum verwendest Du überhaupt waitForReadyRead() - ich mein - dafür gibt es doch nunmal das Signal readyRead() ...
MfG Christian
'Funktioniert nicht' ist keine Fehlerbeschreibung
'Funktioniert nicht' ist keine Fehlerbeschreibung
Re: Chat-Server
Der Thread der erzeugt wird und den Verteiler erzeugt muss irgendwie am Laufen gehalten werden. Dafür verwende ich waitForReadyRead das eben solange blockiert bis readyRead emitiert wird.Christian81 hat geschrieben:Warum verwendest Du überhaupt waitForReadyRead() - ich mein - dafür gibt es doch nunmal das Signal readyRead() ...
Was ich brauche ist das gleiche nur readyRead() OR meinSignal (das eben emitiert werden soll falls in dem Stapel Daten sind).
-
Christian81
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Re: Chat-Server
Sorry aber warum muss der Thread am laufen gehalten werden? Lass ihn einfach in exec() idlen und warte auf das readyRead() - Signal!
MfG Christian
'Funktioniert nicht' ist keine Fehlerbeschreibung
'Funktioniert nicht' ist keine Fehlerbeschreibung
Re: Chat-Server
Ok, danke, genau das was ich gesucht habe. Hatte das sogar schon mal im Code, aber dann wieder gelöscht weil ich noch ein Problem mit den Signals/Slots des Threads hatte (jetzt hat der Thread selbst keine Slots mehr).Christian81 hat geschrieben:Sorry aber warum muss der Thread am laufen gehalten werden? Lass ihn einfach in exec() idlen und warte auf das readyRead() - Signal!
Dann bleibt nur die optinale Frage übrig:
Ist das was ich mache ok von der Herangehensweise? Ich habe gelesen dass man Netzwerkverbindungen nicht mit Threads machen sollte, wobei aber nicht genau erklärt wurde was schlecht daran ist.
Und die ursprüngliche Frage:
Wie realisiere ich selbst ein waitForReadRead? Also zB ein waitForReadyReadOrWrite()? Auf was baut so etwas auf? (interessiert mich einfach, mein Problem ist jetzt gelöst)
-
Christian81
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Re: Chat-Server
Es steht nicht da dass man es nicht machen sollte sondern nur dass man aufpassen muss. Man darf z.B. nicht QTcpSocket::nextPendingConnection() verwenden da dieses Objekt sonst im falschen Thread liegt. Und nötig ist es auch nicht wirklich solange man nicht ewig Performance benötigt (wo man Qt dann ggf. komplett weglassen sollte) da der QTcpSocket nunmal schön asynchron arbeitet wie Du siehst. Der Thread macht bei Dir also im Grunde überhaupt keinen Sinn.
Zu der anderen Frage - das ist recht platformspezifisch. Unter Windows z.B. mit WaitForMutlipleObjects
Zu der anderen Frage - das ist recht platformspezifisch. Unter Windows z.B. mit WaitForMutlipleObjects
MfG Christian
'Funktioniert nicht' ist keine Fehlerbeschreibung
'Funktioniert nicht' ist keine Fehlerbeschreibung