Problem by subclassing the QIODevice

[erqsor]

Hello,

We can read this in the Qt Documentation (in the QIODevice class description):

By subclassing QIODevice, you can provide the same interface to your own I/O devices. Subclasses of QIODevice are only required to implement the protected readData() and writeData() functions. QIODevice uses these functions to implement all its convenience functions, such as getChar(), readLine() and write(). QIODevice also handles access control for you, so you can safely assume that the device is opened in write mode if writeData() is called.

So I tried to subclass QAbstractSocket by reimplementing readData and writeData, but I can't read any data.
I tried readAll, getChar and reading data with a QDataStream and that didn't work.
When I reimplement readAll and getChar by using my readData, that works fine.
So do you think that reimplementing readData and writeData is really sufficient ? Have I to reimplement other functions ?

[erqsor]

A lil up ?

[wysota]

It is sufficient for reimplementing QIODevice, not for reimplementing a subclass of QIODevice which itself customizes the behaviour of a couple of methods from QIODevice.

[erqsor]

OK, Thanks, that's interesting.
Do you have an idea of the functions I have to reimplement ?

I begin by implementing the common ways to read data from a QAbsctratSocket.

[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.

[wysota]

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).

[erqsor]

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...

[wysota]

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.

[erqsor]

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.