[Libwebsockets] Broken behaviour of flow control?
andrejs.hanins at ubnt.com
Wed Oct 21 17:36:47 CEST 2015
I'm trying to use libwebsocket_rx_flow_control(..., 0) function to stop LWS_CALLBACK_[CLIENT]_RECEIVE from being called, but it seems that it either doesn't work in all cases or not designed to work as I expect.
In my scenario, the client establishes an outgoing connection, gets LWS_CALLBACK_CLIENT_ESTABLISHED callback and immediately (right from inside the callback) calls libwebsocket_rx_flow_control(..., 0) to block any further readings from the socket. However, if other side of the connection sends some websocket frame right after connection is established, then client still gets LWS_CALLBACK_[CLIENT]_RECEIVE even though servicing of receiving packet is supposed to be disabled.
As I see, the problem is related to the fact, that libwebsocket_rx_flow_control() function just sets LWS_RXFLOW_PENDING_CHANGE flag, but doesn't actually change the FD polling mode immediately (at least in case when it is called from the LWS_CALLBACK_CLIENT_ESTABLISHED callback). So if there is already some data available for reading from the socket, the libwebsocket_service_fd()->libwebsocket_read() sequence will trigger even if LWS_RXFLOW_ALLOW is *not* set.
For me it looks like a bug. From the other side, maybe LWS library authors didn't have such strict behavioural requirements for flow control and I shouldn't expect that libwebsocket_rx_flow_control() function will immediately block all further receiving activity, instead it should be considered more like an *indication* to stop servicing input packets as soon as possible (which may be delayed in practice).
Would be nice to hear authors' comments! Thanks in advance.
More information about the Libwebsockets