Problem by subclassing the QIODevice

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

[wysota]

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.

[erqsor]

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 !

[wysota]

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:

void	connectToHost ( const QString & hostName, quint16 port, OpenMode openMode = ReadWrite )
void	connectToHost ( const QHostAddress & address, quint16 port, OpenMode openMode = ReadWrite )
QNetworkProxy	proxy () const
void	setProxy ( const QNetworkProxy & networkProxy )
bool	waitForConnected ( int msecs = 30000 )
bool	waitForDisconnected ( int msecs = 30000 )

void	connectToHost ( const QString & hostName, quint16 port, OpenMode openMode = ReadWrite )
void	connectToHost ( const QHostAddress & address, quint16 port, OpenMode openMode = ReadWrite )
QNetworkProxy	proxy () const
void	setProxy ( const QNetworkProxy & networkProxy )
bool	waitForConnected ( int msecs = 30000 )
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:

read()
write()
close()
bytesAvailable()
signal readyRead()
signal bytesWritten()
QHostAddress peerAddress()
quint16 peerPort()

read()
write()
close()
bytesAvailable()
signal readyRead()
signal bytesWritten()
QHostAddress peerAddress()
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?

[erqsor]

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.

[wysota]

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.

[erqsor]

Yes, you said interesting things, but I really want to construct my API like the QTcpSocket and QUdpSocket (and other sockets), That's why I did it like this. I don't want to limit my users. For a personnal project, I will do like you say, but here I think I can't do that :/

Anyway, I did some functions that works:

qint64 QWsSocket::bytesAvailable() const
{
	return buffer.size();
}
 
qint64 QWsSocket::readData( char * data, qint64 maxSize )
{
	int dataSize=buffer.size();
	int i=0;
	while( i<maxSize && i<dataSize )
	{
		data[i] = buffer.dequeue().toAscii();
		i++;
	}
	return i;
}
 
qint64 QWsSocket::writeData( const char * data, qint64 maxSize )
{
	return tcpSocket->write(data, maxSize);
}
 
 
QByteArray QWsSocket::readAll()
{
	qint64 sz = bytesAvailable();
	char * data = new char[sz];
	sz = readData(data, sz);
	return QByteArray(data, sz);
}
 
bool QWsSocket::getChar(char * c)
{
	*c = 0;
	if ( bytesAvailable() == 0 )
		return false;
 
	readData(c, 1);
	return true;
}
 
qint64 QWsSocket::read(char * data, qint64 maxSize)
{
	return readData(data, maxSize);
}

qint64 QWsSocket::bytesAvailable() const
{
	return buffer.size();
}

qint64 QWsSocket::readData( char * data, qint64 maxSize )
{
	int dataSize=buffer.size();
	int i=0;
	while( i<maxSize && i<dataSize )
	{
		data[i] = buffer.dequeue().toAscii();
		i++;
	}
	return i;
}

qint64 QWsSocket::writeData( const char * data, qint64 maxSize )
{
	return tcpSocket->write(data, maxSize);
}


QByteArray QWsSocket::readAll()
{
	qint64 sz = bytesAvailable();
	char * data = new char[sz];
	sz = readData(data, sz);
	return QByteArray(data, sz);
}

bool QWsSocket::getChar(char * c)
{
	*c = 0;
	if ( bytesAvailable() == 0 )
		return false;
	
	readData(c, 1);
	return true;
}

qint64 QWsSocket::read(char * data, qint64 maxSize)
{
	return readData(data, maxSize);
}

To copy to clipboard, switch view to plain text mode 

[wysota]

but I really want to construct my API like the QTcpSocket and QUdpSocket (and other sockets)

What other sockets?

I don't want to limit my users

That's what you're currently doing.

qint64 QWsSocket::bytesAvailable() const
{
	return buffer.size();
}

qint64 QWsSocket::bytesAvailable() const
{
	return buffer.size();
}

To copy to clipboard, switch view to plain text mode 

That's incorrect. See docs for QIODevice::bytesAvailable().

QByteArray QWsSocket::readAll()
{
	qint64 sz = bytesAvailable();
	char * data = new char[sz];
	sz = readData(data, sz);
	return QByteArray(data, sz);
}

QByteArray QWsSocket::readAll()
{
	qint64 sz = bytesAvailable();
	char * data = new char[sz];
	sz = readData(data, sz);
	return QByteArray(data, sz);
}

To copy to clipboard, switch view to plain text mode 

That's incorrect. readAll() is not virtual.

qint64 QWsSocket::read(char * data, qint64 maxSize)
{
	return readData(data, maxSize);
}

qint64 QWsSocket::read(char * data, qint64 maxSize)
{
	return readData(data, maxSize);
}

To copy to clipboard, switch view to plain text mode 

Incorrect, read() is not virtual.