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