QTcpServer mit OpenMode = WriteOnly

[Carolin Z. (seobalis)]

Hallo Leute,

ich habe ein writeOnly-tcp server geschrieben. der Programmcode sieht 
wie folgt aus:

class tcpMainServer : public QTcpServer
{
    Q_OBJECT
public:
    tcpMainServer(QObject *parent = 0);

protected:
    void incomingConnection(int socketDescriptor) {
         QTcpSocket *client = new QTcpSocket (this);
         client->setReadBufferSize(1024);
         if(client->setSocketDescriptor(socketDescriptor,  QAbstractSocket::ConnectedState, QIODevice::WriteOnly)) {
            
        }
        else {
            delete client;
        }
    };

signals:

private slots:

private:

};

Die Idee ist, dass der Server nur senden soll, aber man kann ja nie 
genau wissen was der client macht. Sobald ich mit dem client-test 
anfange zu senden, dann nach eine kurze zeit stützt mein server ab. Ist 
es nicht so dass der Server tcpstream bremst und der client nicht weiter 
senden soll oder kann???
Für euere Hilfe bin ich sehr dankbar.

Grüße,
Carolin

[Εrnst B. (ernst)]

Dumme Frage:
Warum die Reimplementierung von incomingConnection, warum überhaupt von 
QTcpServer erben?

Den kann man "einfach so" verwenden, dann erzeugt er selber die 
QTcpSockets, und alarmiert darüber per "newConnection"-Signal.
(Bei Empfang des newConnection Signals per nextPendingConnection 
abholen)

Vorteil: Die QTcpSockets sind dann tatsächlich mit der richtigen, 
gerade angenommenen Netzwerkverbindung verknüpft.

[Carolin Z. (seobalis)]

Εrnst B✶ schrieb:
> Dumme Frage:
> Warum die Reimplementierung von incomingConnection, warum überhaupt von
> QTcpServer erben?
>
weil ich dann mit thread und andere class(mit public als QTcpSocket) 
flexibel arbeiten kann.
> Den kann man "einfach so" verwenden, dann erzeugt er selber die
> QTcpSockets, und alarmiert darüber per "newConnection"-Signal.
> (Bei Empfang des newConnection Signals per nextPendingConnection
> abholen)
>
> Vorteil: Die QTcpSockets sind dann tatsächlich mit der richtigen,
> gerade angenommenen Netzwerkverbindung verknüpft.
dann hat der TcpSocket den ReadWrite OpenMode. Das ist nicht das, was 
ich haben will. Ich will in dem Fall WriteOnly mode haben.

Und den Vorteil hat man ja, wenn man mit einzelne Verbindung arbeitet 
nicht mit "Multitasking"

Grüße,
Carolin

[Εrnst B. (ernst)]

Ok, Threadübergreifende QTcpSocket objekte...
Braucht man nicht unbedingt, aber sonst langweilen sich ja 7 der 8 cores 
:)
(Mehrere gleichzeitige Verbindungen kann man auch gut mit nur einem 
thread abarbeiten, die QT Event-Loop abstrahiert das alles)

Egal: Du darfst den QTcpSocket nicht mit parent=QTcpServer im selben 
Thread initialisieren, sonst darf der wieder nur in dem Thread verwendet 
werden, in dem der QTcpServer läuft.

Stattdessen: den "int socketDescriptor" an den Worker-Thread übergeben, 
und dort das QTcpSocket Objekt anlegen.

(Edit: Klarstellung: Auch nicht im Konstruktor deines 
Thread-Worker-Objektes. in dessen run()-Methode!)

[Rolf Magnus (Gast)]

Carolin Zapa schrieb:
> dann hat der TcpSocket den ReadWrite OpenMode. Das ist nicht das, was
> ich haben will. Ich will in dem Fall WriteOnly mode haben.

Warum muß der so zwingend WriteOnly sein? TCP kennt eine derartige 
Betriebsart gar nicht. Was soll mit ankommenden Daten denn passieren?

[Εrnst B. (ernst)]

Rolf Magnus schrieb:
> Warum muß der so zwingend WriteOnly sein? TCP kennt eine derartige
> Betriebsart gar nicht.

dochdoch... "Half open Sockets".... vermutlich ähnlich selten verwendet 
wie Out-Of-Band Data..

aus der Posix-Manpage:

shutdown - shut down part of a full-duplex connection

#include <sys/socket.h>

int shutdown(int s , int how );

The  shutdown() call causes all or part of a full-duplex connection on 
the socket associated with sockfd to be shut down.  If how is SHUT_RD, 
further receptions will be disallowed.  If how is SHUT_WR, further 
transmissions will be disallowed.  If how is SHUT_RDWR, further 
receptions and transmissions will be disallowed.