[Development] QWebsocket remark

[Martin Koller]

Hi Kurt,

On Wednesday 19 February 2014 08:14:21 Kurt Pattyn wrote:
> Hi Martin,
> > On 17 Feb 2014, at 19:39, Martin Koller <kollix at aon.at> wrote:
> > 
> > Hi,
> > 
> > had a quick look into the implementation as I wanted to use it in my existing webserver.
> > However, the API does not provide a way to use it for an _existing_ tcp communication channel.
> Do you mean a QTcpSocket?

for example, yes. But it would be nice to be able to use any QIODevice or just a QByteArray
(In fact in my existing app it is just an OS file descriptor)

> > What would be great is if you modify QWebSocketDataProcessor in some way so that it just
> > get's data from anywhere and therefore also make it a public class.
> Well, it takes a QIODevice as data source, so that shouldn't be a problem (as you stated yourself).
> As you probably know, there is a feature freeze for Qt 5.3; so changing the API is currently not a good idea.
> Instead of making QWebSocketDataProcessor public, could you live with the (now private) upgradeFrom() method? This method is actually taking a QTcpSocket and 'upgrades' it to a QWebSocket.

well, probably, but it needs the now still private classes QWebSocketHandshake* as argument, so I fear this
is also not a solution for 5.3

> Do you process the handshake yourself?

yes

> The dataprocessor only takes care of data after a successful handshake has been exchanged.

yes, that was my impression.
I was just looking for a way to handle the websocket protocol itself when the websocket was already
established.

> It is however a very interesting use case and should definitely be explored further.
> Can you add a feature request in Jira?

I'll do ... https://bugreports.qt-project.org/browse/QTBUG-36952

> > 
> > I see it's currently reading from an QIODevice which should be ok, but what is unfortunate
> > is that QWebSocketFrame::readFrame(pIoDevice); blocks!
> > 
> > The problem is exactly what you already wrote as comment there:
> >        case PS_WAIT_FOR_MORE_DATA:
> >            //TODO: waitForReadyRead should really be changed
> >            //now, when a websocket is used in a GUI thread
> >            //the GUI will hang for at most 5 seconds
> >            //maybe, a QStateMachine should be used
> I know, I will finetune this when I start with stress tests. Expect this to be changed in an upcoming release.

Great, thanks

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\                                   - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at