Greetings @Rick164
Yet another websocket issue, first it was the config write (you remember) and now it's also reading as your config exceeds a buffer.
I bet it's the server, because i can add 400 leds and it works fine on 64bit, i increased to 800 and now i have the same issue. You are using a Pi/32bit OS?
However, there are three solutions.
The second option is my fav, as it is more native and doesn't require additional lib compilation _when_ we reach qt5.9 as min version. To be honest, this might be in 2022 if you keep a "os releases over last 4 years are supported".
To make sure i am right that a proper websocket server fixes this (I really want to avoid a reinvention of wheel), i plan to implement the qt5.3 websocket server with it's own port for testing. I will keep you updated.
I am currently working on multi process management, if i am done i will have a look at this.
Have a nice weekend,
brindosch
PS: As i implemented the json-rpc at http level it is a higher interest to move the config write again to the json-rpc itself instead webserver only. It was a subsequent hack of the websocket issues
Edit2: There is no problem with http jsonrpc, it all comes down to websocket server
Um auch mal meinen Senf dazu zu geben. 
Die Einschränkung in Hyperion liegt immer noch hier: https://github.com/hyperion-pr…nClientConnection.cpp#L74
Infos zur Fragmentierung: https://tools.ietf.org/html/rfc6455#section-5.4
Ja und nein, das läuft jetzt genau anders herum. https://github.com/hyperion-pr…ClientConnection.cpp#L212
Der Server schiebt Daten, die nicht komplett gelesen werden können, sei es wegen dem mask oder anderem. Wenn ich das richtig verstanden habe. Das passiert auch wenn zb der base64 string vom image stream größer als 500x500px wird.
Zum server schreiben
qtWebsocket erlaubt ein lesen per Frame, aber auch komplett (nehme ich an, steht indirekt drunter -> http://doc.qt.io/qt-5/qwebsocket.html#textFrameReceived) das erspart das zusammensetzen bis der FIN kommt. Momentan wird erwartet, dass der FIN in jeder msg drin steht, tut es das nicht, gibts nen quit. Richtig?
Senden
Ich hab nicht nachgesehen was dahinter passiert. Die länge eines QStrings ist drin: http://doc.qt.io/qt-5/qwebsocket.html#sendTextMessage
Also theoretisch müsste das alle Probleme die man jetzt hat und für die Zukunft (wss) beseitigen. Ich schätze IE11 läuft dann auch nebenbei.
Praktisch werde ich das testen, wenn ich mit dem hyperiond-starter fertig bin. Ich sehe auch keinen Nutzen den selbst gebastelten mist von 2014(?) zu reparieren 
Schönes Wochenende @Paulchen-Panther ,
brindosch
Der Server schiebt Daten, die nicht komplett gelesen werden können, sei es wegen dem mask oder anderem. Wenn ich das richtig verstanden habe. Das passiert auch wenn zb der base64 string vom image stream größer als 500x500px wird.
Ich glaube nicht. Der Server kürzt die Message einfach ab. Die Fehlermeldung von Rick164 sagt ja nicht umsonst "end of data":
[websocket::onmessage] SyntaxError: JSON.parse: end of data after property value in object at line 1 column 16466 of the JSON dataHier ein anderer Beispielcode: https://github.com/neeraj9/Sig…pWebsocketServer.cpp#L104
Zum server schreiben
qtWebsocket erlaubt ein lesen per Frame, aber auch komplett (nehme ich an, steht indirekt drunter -> http://doc.qt.io/qt-5/qwebsocket.html#textFrameReceived) das erspart das zusammensetzen bis der FIN kommt. Momentan wird erwartet, dass der FIN in jeder msg drin steht, tut es das nicht, gibts nen quit. Richtig?
Könnte man so sagen, aber das zusammensetzten übernimmt QT für dich. Wenn du den QtWebsocket Server portieren möchtest, wird dir nichts anderes übrig bleiben als mit den FIN bit zu arbeiten.
Der Server kürzt die Message einfach ab
Ich hab mal im source code gewühlt. Frame zerhacker ist da -> https://github.com/qt/qtwebsoc…ets/qwebsocket_p.cpp#L753
Könnte man so sagen, aber das zusammensetzten übernimmt QT für dich. Wenn du den QtWebsocket Server portieren möchtest, wird dir nichts anderes übrig bleiben als mit den FIN bit zu arbeiten.
Ich schätze die Wahl hat man so oder so nicht, der spec will es so. Eigentlich will ich mit WebSocketServer::handleConnection(TcpSocket) nen upgrade machen. Allerdings ist mir das etwas schleierhaft wie das gehen soll. In dem Moment in dem du feststellst, dass der request nen handshake ist, läuft der parsing Vorgang schon und handleConnection() setzt direkt bei nextPendingConnection() an um dann auf den handshake zu warten. Vielleicht sehe ich auch den springenden Punkt nicht und die Lücke füllt sich von allein mit einer Wiederholung oder ähnlichem.
Natürlich könnte man die betreffenden codezeilen auch kopieren um eine Verarbeitung von und zu frames zu haben. Wäre eine kurzfristige Lösung des Problems.
@Rick164
Depending on available time a quick solution will be to copy the frame creation and extraction for proper writing and reading for websockets. Our implementation is simply incomplete. The long runner here is together with ssl support the use of qts own websocket implementation because it's already done and i don't want to take care of future updates for such lowlvl stuff.
Ah I see, German is a bit rusty here so if I understand correctly in future updates this will be handled better due to a more recent qt websocket implementation?
At the moment this is fine though and is pretty much a rare case to have this amount of leds anyway so no rush, can live without the web interface and do the config edition manually like with V1
Running Rpi 3 (64-bit) but can also test on earlier models if needed.
Sorry for that,
i want to resolve it rather now than later, the webconfig write should move again to the json-rpc processing, as it is currently just possible via webserver. So it is not available for tcpsockets and websockets which is just a bad design and as i implemented http json-rpc support it is more than welcome to make it that way available to all communication ways now and in future (udp for example).
No worries, my C++ skills are mediocre but let me know if you need a hand as we can probably brainstorm
Done, leave some feedback
https://github.com/hyperion-project/hyperion.ng/pull/460
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
