Results 1 to 20 of 42

Thread: Problem by subclassing the QIODevice

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Jun 2010
    Posts
    34
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Problem by subclassing the QIODevice

    OK, I thought that was a transport layer.

    I'm not closed to any suggestion, but here I don't understand how you can etablish the connexion.
    In my case, the C++ application is on the server side, and the javascript web application is on the client side, and this web application send the first request.
    So the first thing I have to do in the C++ application is to receive a request, and not send requests. How can you do that with QNetworkAccessManager::createRequest ?
    Or do you have a turorial/example ?
    Last edited by erqsor; 16th January 2012 at 14:57.

  2. #2
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,373
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Thanks
    3
    Thanked 5,019 Times in 4,795 Posts
    Wiki edits
    10

    Default Re: Problem by subclassing the QIODevice

    Quote Originally Posted by erqsor View Post
    OK, I thought that was a transport layer.
    If I understand how WebSockets work, they make a request over HTTP which is above the transport layer (TCP serves as the transport layer).

    I'm not closed to any suggestion, but here I don't understand how you can etablish the connexion.
    Qt is open source, take a look there

    In my case, the C++ application is on the server side, and the javascript web application is on the client side, and this web application send the first request.
    Then I have totally no idea why you want to have a subclass of QAbstractSocket. You should have something similar to QTcpServer which is not derived from either QIODevice or QTcpSocket.

    What you are implementing is a regular HTTP server serving regular HTTP requests. I don't know what your web application does but unless it tries to do arbitrary streaming over websocket API (which is doubtful) there is really no point in deriving anything from QAbstractSocket.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  3. #3
    Join Date
    Jun 2010
    Posts
    34
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Problem by subclassing the QIODevice

    If I understand how WebSockets work, they make a request over HTTP which is above the transport layer (TCP serves as the transport layer).
    Yes, the client side is Google Chrome or Mozilla Firefox.
    This client send the first HTTP request.
    So by my side (server side), I have to get a client request (to etablish a connexion). And up to now, I used sockets to reply other requests.

    You can read the ref here : http://tools.ietf.org/html/draft-iet...ketprotocol-17

    Thats not "my" application. I'm making a generic API (webserver socket with Qt). So users can do simple requests or streaming, etc... (what they want...).
    So for now, I give to my API users a QWsSocket with which they can communicate with different clients.


    Added after 13 minutes:


    I looked this documentation (In French, sorry) http://qt.developpez.com/doc/4.7/qnetworkaccessmanager/
    And they speak about requests sended by the server to receive replies.
    But here I'm doing the opposite. So if you want, I could qnetworkaccessmanager if I had to developpe a client application, but here I need to develop a server application. Thats not the server which requests the clients, but clients which requests the server.
    Last edited by erqsor; 16th January 2012 at 21:35.

  4. #4
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,373
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Thanks
    3
    Thanked 5,019 Times in 4,795 Posts
    Wiki edits
    10

    Default Re: Problem by subclassing the QIODevice

    Quote Originally Posted by erqsor View Post
    I'm making a generic API (webserver socket with Qt). So users can do simple requests or streaming, etc... (what they want...).
    So for now, I give to my API users a QWsSocket with which they can communicate with different clients.
    The thing is there is no benefit in returning a subclass of QAbstractSocket. Of course it is technically possible to do that however in my personal opinion it is better to deliver an object more similar to QNetworkReply --- something that contains the headers of the request and means to read the body of the request through QIODevice API.

    I looked this documentation (In French, sorry) http://qt.developpez.com/doc/4.7/qnetworkaccessmanager/
    And they speak about requests sended by the server to receive replies.
    But here I'm doing the opposite.
    Yes, I know. You can't use QNAM. When I was suggesting that I was under impression you were interested in the client side (because of your interest in QAbstractSocket instead of QTcpServer).
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  5. #5
    Join Date
    Jun 2010
    Posts
    34
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Problem by subclassing the QIODevice

    OK, you say that I'm interested by the client side because I'm using sockets.
    So you think I don't need sockets in my server application.
    So I'm interested to know, when a connexion is etablished with a client by the QTcpServer, how do you send data to this client ?
    personaly, I don't know how to do this without using the socket of this client...

  6. #6
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,373
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Thanks
    3
    Thanked 5,019 Times in 4,795 Posts
    Wiki edits
    10

    Default Re: Problem by subclassing the QIODevice

    Quote Originally Posted by erqsor View Post
    OK, you say that I'm interested by the client side because I'm using sockets.
    No. I thought you were interested in the client side because QAbstractSocket represents a client side of the connection. The server is implemented by Q*Server.

    So I'm interested to know, when a connexion is etablished with a client by the QTcpServer, how do you send data to this client ?
    personaly, I don't know how to do this without using the socket of this client...
    I'm not saying you shouldn't be using sockets! I'm saying that you should give your users an API that more resembles QNetworkReply than QTcpSocket. Internally you will use a tcp socket but you shouldn't expose that socket to the outside world.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  7. #7
    Join Date
    Jun 2010
    Posts
    34
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Problem by subclassing the QIODevice

    OK, so can you tell me how can I replace my QTcpServer by a QNetworkReply ? The QtAssistant doesn't illustrate this case...
    For now, I'm using the QTcpServer::listen function for waiting client connexions, and creating a QTcpSocket to communicate with this client.

  8. #8
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,373
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Thanks
    3
    Thanked 5,019 Times in 4,795 Posts
    Wiki edits
    10

    Default Re: Problem by subclassing the QIODevice

    Quote Originally Posted by erqsor View Post
    OK, so can you say to me how can I replace my QTcpServer by a QNetworkReply ? The QtAssistant doesn't illustrate this case...
    For now, I'm using the QTcpServer::listen function for waiting client connexions, and creating a QTcpSocket to communicate with this client.
    Come on. Read my posts carefully, I never said you should replace QTcpServer with QNetworkReply.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  9. #9
    Join Date
    Jun 2010
    Posts
    34
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Problem by subclassing the QIODevice

    Ok, misunderstanding, sorry...

    No. I thought you were interested in the client side because QAbstractSocket represents a client side of the connection. The server is implemented by Q*Server.
    But I need sockets in server side ^^

    Anyway, I wanted to do my API like this : The user uses these two ws objects (QWsServer, QWsSocket) as he uses these two tcp objects (QTcpServer, QTcpSocket).
    The user don't use tcp objects: The TCP instructions are done in background (hidden).

    As I said at begining, I have some problems :
    - Inherit the QWsServer from QTcpServer : I can't because the newConnection signal is already used in background by the QTcpServer. And I can't offer this signal to the QWsServer users by inheritance.
    - Inherit the QWsSocket from QTcpSocket : I can't for the same reason with the readyRead signal.

    So I have not used inheritance, but aggregation (I don't know if thats the right word in English). So the QWsServer has a ptr to a QTcpServer as member. And the QWsSocket has a QTcpSocket ptr as member too.
    QWsServer inherits from QObject and QWsSocket inherits from QAbstratSocket.
    And finaly, for now I created my own signals and fonctions to read data in a QWsSocket, but I wanted to use the QAbstractSocket features to the fullest, and so reimplementing the common read functions and signals.

    I hope what I said is clear !
    Last edited by erqsor; 17th January 2012 at 00:19.

  10. #10
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,373
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Thanks
    3
    Thanked 5,019 Times in 4,795 Posts
    Wiki edits
    10

    Default Re: Problem by subclassing the QIODevice

    Quote Originally Posted by erqsor View Post
    As I said at begining, I have some problems :
    - Inherit the QWsServer from QTcpServer : I can't because the newConnection signal is already used in background by the QTcpServer. And I can't offer this signal to the QWsServer users by inheritance.
    - Inherit the QWsSocket from QTcpSocket : I can't for the same reason with the readyRead signal.

    So I have not used inheritance, but aggregation (I don't know if thats the right word in English). So the QWsServer has a ptr to a QTcpServer as member. And the QWsSocket has a QTcpSocket ptr as member too.
    QWsServer inherits from QObject and QWsSocket inherits from QAbstratSocket.
    And finaly, for now I created my own signals and fonctions to read data in a QWsSocket, but I wanted to use the QAbstractSocket features to the fullest, and so reimplementing the common read functions and signals.
    That's all ok however in my opinion there is just no point in deriving your QWsSocket from QAbstractSocket. QIODevice would do just fine and you could reimplement only those methods you really needed (unfortunately not only the two you mentioned in the beginning).

    And here is why I think the way I think... Unless you want to implement the client side as well, your QWsSocket won't sanely implement the following methods from QAbstractSocket:

    Qt Code:
    1. void connectToHost ( const QString & hostName, quint16 port, OpenMode openMode = ReadWrite )
    2. void connectToHost ( const QHostAddress & address, quint16 port, OpenMode openMode = ReadWrite )
    3. QNetworkProxy proxy () const
    4. void setProxy ( const QNetworkProxy & networkProxy )
    5. bool waitForConnected ( int msecs = 30000 )
    6. bool waitForDisconnected ( int msecs = 30000 )
    To copy to clipboard, switch view to plain text mode 

    So what is the point in having those methods around?

    Correct me if I'm wrong, but what your users need is:
    Qt Code:
    1. read()
    2. write()
    3. close()
    4. bytesAvailable()
    5. signal readyRead()
    6. signal bytesWritten()
    7. QHostAddress peerAddress()
    8. quint16 peerPort()
    To copy to clipboard, switch view to plain text mode 

    Apart from the last two methods the rest is defined in QIODevice. So you are leaving 6 dangling methods just for the benefit of having other two methods that are pretty simple to implement.

    A potential advantage of subclassing QAbstractSocket would be if someone wanted to replace one socket implementation for another. Unfortunately protocols differ so much that in 99% of the cases it is just not possible (and where it is possible, you can just use QIODevice API). So what is the point of deriving from QAbstractSocket?
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  11. #11
    Join Date
    Jun 2010
    Posts
    34
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Problem by subclassing the QIODevice

    I developped an application with my API (So that's a project that uses my websocket server API). And I found usefull to allow server to permit connexion by using one QTcpServer and one QWsServer (So users can connect by two ways : a Qt application that uses TCP protocol, and a web application that uses websocket protocol). And next I stored the socket with a total abstraction of the protocol in a member of my client class (QAbstractSocket * socket) that can stores a QTcpSocket or a QWsSocket (never both). And I want to use the write and read methods with a total abstraction of the type of the socket to simplify and make more powerful the use of the API.
    I want users uses the QWsSocket like a QTcpSocket, so I redirect the peerAddress, peerPort, state, socketType functions to the QAbstractSocket (and I need too the connected, disconnected, stateChanged signals). So if my QWsSocket doesn't inherit from QAbstractSocket, I can't use this network part of QIODevice I need.
    Last edited by erqsor; 17th January 2012 at 01:36.

  12. #12
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,373
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Thanks
    3
    Thanked 5,019 Times in 4,795 Posts
    Wiki edits
    10

    Default Re: Problem by subclassing the QIODevice

    The abstraction of the protocol probably could have as well used QIODevice instead of QAbstractSocket (since protocols care only about data exchange and not who they are talking to and how). The signal connected() is useless on the server side since when the server accepts a connection, the socket is already in the connected state. Disconnected() is pretty much useless for the server as well and even if not, adding that signal is not a problem. The only two meaningful SocketState values for the server side of the connection are Connected and Closing since the server is accepting the connection so it doesn't do host lookup, it doesn't connect and it's not listening (since it is an incoming connection). However, I'm not going to convince you anymore, it is your project and I just hope people using your code think exactly the same way you do, otherwise you'll get a lot of stupid "why doesn't it work" questions from them.

    By the way, there is this thing called QLocalSocket. It's derived from QIODevice and not QAbstractSocket. To be honest I wondered many times why QUdpSocket inherits QAbstractSocket since it's neither connecting nor streaming. I wouldn't be suprised if in Qt5 QAbstractSocket simply vanished into thin air.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


Similar Threads

  1. QIODevice read() problem (reads more than maxSize)
    By m15ch4 in forum Qt Programming
    Replies: 0
    Last Post: 22nd February 2011, 11:09
  2. Subclassing QSortFilterProxyModel problem
    By e79ene in forum Newbie
    Replies: 2
    Last Post: 21st February 2011, 13:23
  3. Phonon: subclassing QIODevice
    By iDm.MuFFin123 in forum Qt Programming
    Replies: 0
    Last Post: 23rd May 2010, 13:29
  4. Subclassing QMainWindow problem
    By lerwys in forum Qt Programming
    Replies: 7
    Last Post: 28th April 2009, 08:40
  5. Problem with QTreeWidget after subclassing
    By steve918 in forum Qt Programming
    Replies: 2
    Last Post: 28th July 2006, 18:51

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Qt is a trademark of The Qt Company.