Unable to connect on Windows 10

[hokyungh]

After upgrading my libwebsockets to use https://github.com/warmcat/libwebsockets/commit/754d2b4578ffb5bc49b82f9988fdf8e339876743. I have found that I can no longer connect. I am on Windows 10 machine.

[2023/06/01 19:45:03:6843] N: __lws_lc_tag:  ++ [wsi|0|pipe] (1)
[2023/06/01 19:45:03:7023] N: __lws_lc_tag:  ++ [vh|0|default||-1] (1)
[2023/06/01 19:45:03:7223] N: lws_plat_vhost_tls_client_ctx_init: Imported 48 certs from plat store
[2023/06/01 19:45:03:7223] D: (hexdump: zero length)
[2023/06/01 19:45:03:7233] D: (hexdump: zero length)
[2023/06/01 19:45:18:8023] N: __lws_lc_untag:  -- [wsi|0|pipe] (0) 15.117s
[2023/06/01 19:45:18:8023] D: (hexdump: zero length)
[2023/06/01 19:45:18:8033] N: __lws_lc_untag:  -- [vh|0|default||-1] (0) 15.100s
[2023/06/01 19:45:18:8043] N: lws_create_context: LWS: 4.3.2-v4.3.2-3-g754d2b45, NET CLI SRV H1 H2 WS ConMon IPv6-absent
[2023/06/01 19:45:18:8073] N: __lws_lc_tag:  ++ [wsi|0|pipe] (1)
[2023/06/01 19:45:18:8082] N: __lws_lc_tag:  ++ [vh|0|default||-1] (1)
[2023/06/01 19:45:18:8233] N: lws_plat_vhost_tls_client_ctx_init: Imported 48 certs from plat store
[2023/06/01 19:45:18:8243] D: (hexdump: zero length)
[2023/06/01 19:45:18:8243] D: (hexdump: zero length)
[2023/06/01 19:45:18:8243] N: __lws_lc_tag:  ++ [wsicli|0|WS/h1/default/signal.m3.ue1.app.chime.aws] (1)
[2023/06/01 19:45:18:9979] D: (hexdump: zero length)
[2023/06/01 19:45:18:9979] D: (hexdump: zero length)
[2023/06/01 19:45:34:0051] E: Error while trying to connect the websocket: Unable to connect

Would you be able to explain what this commit supposes to do?

[lws-team]

@zbroyar Looking at the code, its idea is to make sure we service the same fd slot if that fd closed.

The reason is that the active fd list is pruned by swapping the closing fd's position with the last one. If another fd closed, and the last one we swapped into its place was signalled to have an event, the outer fd event handling loop will otherwise miss the event on the last one. So it gratuitously re-services the fd that was swapped into the fd that just closed to ensure we "get the last one".

It might be that the old last fd in the list is in a state that really cares about getting serviced when there was no actual event to trigger it. In that case checking if any event is signalled on the new fd in the slot before re-servicing should be enough to solve it.

[hokyungh]

Hi @lws-team thanks for the comment. Will that mean this will be reverted back or additional PR will be made on this one?

[lws-team]

I don't have any time to spend on it atm and since it says here zbroyar is in Kyiv, he also will have more important things on his mind.

Basically what needs doing is try change the test added in the patch to be this larger version instead

if (pt->fds[fds_count - 1].revents && pt->fds_count < fds_count)

or fiddle with variations on that until it affects your problem. you're the guy with the symptom so you are the best... best motivated, easiest to reproduce ... guy to look at it.