Websocket handle webui websocket not websocket client is that normal ?

[luc-github]

On ESP3D the webUi use http and websocket on port (http +1) - this websocket use binary mode to stream data ( in read only) and use text mode for several informations exchange

for a standalone websockect client ESP3D use another websocker server and port, this websocket server use text mode for GCODE transfer and reserve binary mode for coming file transfert feature

It seems the grblHAL websocket setting : actually cut the webUI websocket - is that normal ? does it means the websocket client is same between webUi and any other client ? and so only binary mode is available to send commands ?

Just to clarify - not actually a bug but changing websocket setting make the webui to disconnect because it cannot get any stream so it may be troublesome for end user

[terjeio]

The grblHAL websocket server daemon can only have one client connection active that claims serial communication. Other client connections can be established but these have to use a subprotocol that does not claim serial comms. Subprotocols can be text or binary - the server daemon forwards the payload to the code that handles them. You need separate server daemons for each client connection? Each one acting as a serial stream?

[luc-github]

You need separate server daemons for each client connection? Each one acting as a serial stream?

Currently in esp3d using arduino and esp3d-tft using idf - yes I have 2 websocket servers listening on 2 different ports the websocket server webui using webui-v3 as subprotocol is limited to one connection and the other websocket server acting as telnet support (using arduino sub protocol) several clients

If your implementation use only one server daemon I would like to suggest that websocket setting does not start/stop the webui-v3 subprotocol but only the arduino one On otherhand the http setting would start/stop websocket webui-v3 subprotocol as well as http daemon

Just as suggestion to avoid webui to disconnect if websocket is stopped using settings

[terjeio]

the websocket server webui using webui-v3 as subprotocol is limited to one connection and the other websocket server acting as telnet support (using arduino sub protocol) several clients

Telnet over Websocket? Or do you mean the arduino websocket subprotocol provides several independent serial type communications channels/streams, one for each connection? Or do each connection share a single stream?

If your implementation use only one server daemon I would like to suggest that websocket setting does not start/stop the webui-v3 subprotocol but only the arduino one

Subprotocols are not started/stopped, only the websocket daemon is. Subprotocols are "activated" when a client connects, it is a part of the initial handshake.

On otherhand the http setting would start/stop websocket webui-v3 subprotocol as well as http daemon

In grblHAL these are two different daemons and not interdependent. BTW changing the network configuration requires a reset of the controller, grblHAL does not support on-the-fly changes. What I could do is to add sanity checks on port number settings and return an error if there are clashes?

[luc-github]

Telnet over Websocket? Or do you mean the arduino websocket subprotocol provides several independent serial type communications channels/streams, one for each connection? Or do each connection share a single stream?

Sorry I see my writing was confusing. my meaning was websocket client can connect like telnet client can connect. no relation between websocket and telnet - sorry for the confusion

Yes in ESP3D, webui-v3 subprotocol websocket and arduino subprotocol websocket are independent

In grblHAL these are two different daemons and not interdependent Yes HTTP and web socket are not interdependant daemon but Webui need both currently so stopping websocket using webui-v3 sub protocol kind of stop the webui usage.

My suggestion is websocket setting should not stop websocket daemon using webui-v3 subprotocol if it is disabled, but only the usage of websocket using arduino subprotocol if any .

So only disable websocket daemon if http and websocket setting are set to disabled and if only websocket setting is disabled and not http, then only disable the activation of arduino subprotocol

This is just a suggestion from user point of view

[terjeio]

My suggestion is websocket setting should not stop websocket daemon using webui-v3 subprotocol if it is disabled, but only the usage of websocket using arduino subprotocol if any .

The webui-v3 subprotocol is not handled by the websocked daemon, the webui server code does that (except handling the serial stream).

So only disable websocket daemon if http and websocket setting are set to disabled and if only websocket setting is disabled and not http, then only disable the activation of arduino subprotocol

This is not logical for me... The http and websocket daemons are not hardwired to the WebUI, websockets can be enabled without http beeing enabled and vice-versa. If http is disabled then it makes sense for the WebUi server to not respond to/handle the webui-v3 subprotocol - it does now. What I could do is to trap $73 changes and refuse to disable websockets unless http is also disabled, this if the WebUI server is active. Complicated...

[luc-github]

Yes current WebUI use both http and websocket - that is current design Well I did not digged into your code - that is why I asked question

What I could do is to trap $73 changes and refuse to disable websockets unless http is also disabled,

That could be a workarround

[luc-github]

The idea is to avoid this :

[terjeio]

Workaround committed - blocks disabling websocket daemon from the WebUI, can still be disabled from other senders. I have also added disable of the webui-v3 websocket subprotocol if the http daemon is not running.

[luc-github]

Thank you ^_^