[Libwebsockets] Long delay when establishing connection
andy at warmcat.com
andy at warmcat.com
Wed Jun 3 06:38:47 CEST 2020
On June 3, 2020 3:00:19 AM UTC, Heaton Xing <heaton209.x at gmail.com> wrote:
>I use libwebsocket in an embedded system.The main program is an
>loop, it will process an external interrupt every 0.5ms, and call
>lws_service in the interrupt service program.Implemented
Wow... every 500us... you are pretty brave. You're saying nothing on the event loop, lws or user code or network stack can ever take more than 500us or your system misses interrupts. But depending on your system, even libc free() might violate that occasionally.
Your plan about lws_service in the isr doesn't sound good either, it'd be better to implement something an event lib that waits on a sync object triggered in the isr. In v3.2+, lws_service does not return until something woke it from poll wait.
>on the PC side, and found that it takes 2000ms to complete the
... there seems to be a story missing about how you measured it
>Is it because the libwebsocket server is waiting for the connection in
>Is there a similar non-blocking way to create a websocket
>connection?Because our current system is a wireless communication
>if the remote device is connected for a long time, the wireless
>transmission will be interrupted.
On the one hand you're doing something very avant garde but on the other you did not check and realize lws itself is wholly nonblocking. By default it uses libc getaddrinfo, which blocks for an arbitatrary amount of time doing dns resolution. But lws provides LWS_WITH_SYS_ASYNC_DNS option at cmake you can use to replace that with lws internal dns resolver, which is like everything else completely nonblocking.
I guess with nice hardware and two machines in the same room you may be able to send something every 500us reliably over tcp if nothing else happening. But over the internet generally, you cannot 'push' data the same way, like you can't push a piece of string. You can only push as much as the other side is pulling. UDP only helps if you can tolerate loss, otherwise you must reimplement acks and retries manually and that comes out of your time budget too.
You mention wireless, 80211 conceals retries commonly and has its own acks, its performance is inherently nondeterministic.
So unless there are more constraints than you mentioned, you're going to have a hard time making that do what you're thinking, lws aside.
More information about the Libwebsockets