Ich bin gerade dabei für meinen Server die Connections in Threads zu stecken. Jetzt habe ich das Problem, dass er readyRead irgendwie nicht anspricht. Ich bekomme keine Fehlermeldung.
wenn Du selber assynchronitaet herstellen willst/musst ... solltest Du nicht auf assynchrone Funktionalitaeten anderer zurueckgreifen. Sonst kommst du recht schnell durcheinander.
Signale/Slots und generell die Signale an QSockets sind sowas. Die sind da um dir beim synchronen programmieren zu helfen, nicht beim assynchronen.
Besser, wenn selber threades:
in der run Methode synchrone Methoden laufen lassen und auf events blockieren lassen.
bool waitForConnected ( int msecs = 30000 ) am QTCPSocket ist sowas.
Die signale fuers verbinden kannst dann selber werfen !
2. QObject QThread QSocket --- wo laeuft was ?
Du erzeugst deinen QTcpSocket im CTor von clientConnection (Wer benennt klassen noch mit kleinen Anfangs-Buchstaben ? )
Das heisst Der QSocket selber wird im Thread laufen, in dem Auch clientConnection laeuft !
der wiederum lauft in dem thread, in dem er erzeugt wurde ...
(QT Thread affinititaet).
Das heisst im Klartext, alle slots ein deinem QTcpClient werden da drinne laufen ....
dein QThread, der dir ja nen thread erzeugen soll ... was er auch macht .. feuert in deinem Bsp nur die connect methode, dann verabschiedet er sich wieder ^^
Dein readData laeuft natuerlich im Thread des aufrufers ....
das kann wiederum jeder thread sein ... nur nich dein erzeugter, weil der iss da mit sicherheit schon am ende ^^
Also mit Threads, QT, Besonders QT und SignalMapping ueber threadgrenzen solltest dich ausgiebig beschaeftigen !
Warum willst ueberhaupt threaden ???
dein QTcpSocket, wenn den schoen mit assynchronen methoden von QT befeuerst, blockiert dir doch nix ...
RHBaum... einmal mehr verstehst du es, kurz und prägnant zu antworten
@dazedly:
Fehler 1: Dein QTcpSocket lebt im falschen Thread (wie RHBaum erklärt hat). Also: QTcpSocket erst in der run()-Methode erstellen.
Fehler 2: Dein Thread wird gleich wieder beendet (wie RHBaum erklärt hat). Also: exec() am Ende aufrufen.
Fehler 3: Wenn dann der Thread läuft: Beim Empfang hast du noch ein Denkfehler: Woher weisst du, wie viel Speicher "size" (bei "ins >> size") innerhalb des QDataStreams benötigt? Abhilfe: Trenne die Blockgrösse vom DataStream (sende also zuerst einen einzigen int64 und erst danach den QDataStream). Erstelle dann den QDataStream erst, wenn der QByteArray vollständig angekommen ist.
Edit:
Warum ich Threads benutzen will:
Jeder Client muss sich in seinem eigenen Thread authentifizieren und hat in seinem Objekt (Thread) seine eigenen Umgebungsvariablen. Die Kommunikation soll bidirektional sein und nicht blockieren.
Ich habe das Problem jetzt gefunden. Es lag am QTcpServer, bzw an meiner implementierung. Ich hätte nicht das signal "newConnection" connecten dürfen, sondern "incomingConnection" implementieren sollen.
Das Problem war, dass dadurch zwei QTcpSockets offen waren und beide auf den netzwerksocket gelauscht haben. Dadurch war es mehr oder weniger Zufall, an wen die Daten gegangen sind.