[Libwebsockets] Broken behaviour of flow control?

Andrejs Hanins 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.

BR, Andrey 

More information about the Libwebsockets mailing list