Problem by subclassing the QIODevice

[wysota]

Why are you subclassing QAbstractSocket and not QIODevice? What is it exactly that you want to achieve?

[erqsor]

I created a websocket server lib and I'm trying to improve the genericity of my lib.
http://gitorious.org/qtwebsocket

[wysota]

Aren't websockets based on TCP?

[erqsor]

That's true, so I'm using QTcpServer and QTcpSockets in background.
But websockets are over the TCP. So I created a QWsServer and a QWsSocket class.
I created a new signal QWsSocket::frameReceived to get the data, but I want to use the traditional socket signals (readyRead) and functions (read, readData, stream...).
I started it, but as I said, I'm surprised that the Qt documentation say we just have to reimplement the writeData and readData functions.

[wysota]

That's true, so I'm using QTcpServer and QTcpSockets in background.
But websockets are over the TCP. So I created a QWsServer and a QWsSocket class.

Why don't you just subclass QTcpSocket?

I started it, but as I said, I'm surprised that the Qt documentation say we just have to reimplement the writeData and readData functions.

As I said, the docs say so about QIODevice, not QAbstractSocket. The latter reimplements 8 of its superclass methods changing their default behaviour.

[erqsor]

I started by subclassing QTcpSocket. But I had to change this, because how can you use the readyRead signal to read incoming data through the TCP socket and next emiting the same signal to allow QWsSocket users to get the websocket incoming data.
There is an architectural problem

[wysota]

Isn't websocket data related to the tcp data you receive? I don't understand why do you want to mimic QAbstractSocket so much. Either you are dealing with low-level mechanism in which case what QTcpSocket offers is just enough or you want to implement a high-level mechanism (with access to all the headers and stuff) in which case you should probably just implement a backend for QNetworkAccessManager. WebSockets is an application layer concept and QAbstractSocket is a transport layer concept.

[erqsor]

Websockets is a transport layer too. You have to specify data type (binary, text, ...) and frame formats, size, mask, etc...
As I readed, QNetworkAccessManager can be used to send requests and receive answers, how can I etablish a socket connexion like this ?
In my case, I'm the server, I have requests to send, but not only, I have mainly requests to receive and treat.
Thats the aim of the websocket mechanism. Find a alternative to ajax polling by using sockets.

I don't know why do you want I change my architecture ? I just needed some informations on the QIODevice subclassing...

[wysota]

Websockets is a transport layer too. You have to specify data type (binary, text, ...) and frame formats, size, mask, etc...

So it's not a transport layer.

As I readed, QNetworkAccessManager can be used to send requests and receive answers, how can I etablish a socket connexion like this ?

By reimplementing QNetworkAccessManager::createRequest() and making the connection to the server.

I don't know why do you want I change my architecture ? I just needed some informations on the QIODevice subclassing...

I don't want to change your architecture. You are the one complaining about your current architecture. If you ask me, you can even derive your socket from QRect if you really like to do additional work.

[erqsor]

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 ?

[wysota]

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.

[erqsor]

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.