Request: Let Qt app take over (an open) websocket for low level interaction. about cutelyst

[dantti]

Sorry I don't understand what you want.

[dantti]

ping?

[an-hen]

After I've poked around in wsgi code a little bit, I think, that it may not be possible to achieve what I'd like to have. I have also to admit, that maybe, what I want to achieve is not a usual or common use case at all.

Nevertheless I'll try to explain what I meant:
With WSGI it is currently possible to react to web socket events, e.g. by connecting to 'webSocketTextMessage'-signal. But I would love to be able not only to react to certain events, but to get a QWebSocket instance (if some criteria - like certain url for exmaple - are be met) which I can use in underlying qt application.

I could use QWebSockerServer, but then I would need another listening port as WSGI uses.

Maybe wollowing use case will help:
A JavaScript audio player is delievered to user by WSGI and after some user interaction tries to open a websocket connection to obtain audio data for example (url: "ws://mycutelystserver.net/audio/test.mp3"). While on the server such attempt is recognized, and thus corresponding QWebSocket is moved to a 'sending' thread, which sends audio data packet wise and listens for additional commands like 'pause' or 'jump to desired timestamp'. In such scenario I do not only react to some queries with small answers over websocket but actively and continuously send some data.

[dantti]

Ok, first, QWebSocket and Cutelyst websocket implementation provide the same set of features, Cutelyst being in some aspects superior, as it's faster, uses less memory, and is defensive by default, it's quite easy to take down a QWebServer by flooding with loads of data if you don't explicit set a limit.

I really think that streaming is best by simply doing HTTP regular requests, but if you want to use WebSockets there's no problem, first BOTH QWebSocket and Cutelyst WS can't be moved to another thread, so you need to do some async approach, then for both you would probably want to send binary data, which is the same way on both.

In fact both implementations passes with 100% score on autobahn websocket testing.

I think you would like to have access to the low level TCP socket, if so then you are out of lucky with both implementations. Still there's no benefit at all on getting it, because that's not the protocol that clients will talk, maybe your issue is due the misconception of a websocket which isn't related to socket as it is in fact a binary protocol.

[dantti]

I'm closing due inactivity, when in doubt of implementation it's better to ask on the mailing list