I have WiFi in APSTA mode and the webserver will serve http on port 80 on both networks. I have a websocket server using netconn api (for efficiency compared to sockets) on another port.
Once the websocket it opened, it blocks on netconn_recv waiting for data.
If I want to change between AP and STA to serve the webpage, all is fine, but unless the websocket is closed in one network (by closing the browser tab which sends the proper request to close the websocket), it won't open on the other. I'd like the network most recently served a webpage to own the websocket, so I want to be able to shut it down from the server side.
I can detect the event I want to trigger the netconn_close with a structure pointer to the connection, but it doesn't seem to have the same effect as closing the web browser tab that has opened the websocket.
So is there a "nice" way to unblock a netconn_recv by closing or deleting its connection from the server side when the client hasn't been closed?
It might be a good opportunity to redo the webserver and websocket code so they are both on port 80 and use non blocking sockets, but I wondered if there was a simple tweak to do it with netconn.
netconn_close whilst blocked in netconn_recv
Re: netconn_close whilst blocked in netconn_recv
Best solution so far is to use netconn_set_recvtimeout(newconn, timeout) to give netconn_recv a timeout. Existing code tests that netconn_recv returns ESP_OK, in this case it will return a timeout and effectively close the websocket allowing it be opened elsewhere.
Re: netconn_close whilst blocked in netconn_recv
LWIP doesn't support closing a netconn from one task while another task is blocked on it.
(Upstream LWIP also doesn't support doing this for the BSD sockets API, but we've added support for this to the BSD Sockets API in ESP-IDF's LWIP fork.)
What you're doing with a timeout is a good solution.
(Upstream LWIP also doesn't support doing this for the BSD sockets API, but we've added support for this to the BSD Sockets API in ESP-IDF's LWIP fork.)
What you're doing with a timeout is a good solution.
Who is online
Users browsing this forum: Google [Bot], MicroController and 130 guests