Communication delay problem using urequest. #16139
Unanswered
peetery
asked this question in
Libraries & Drivers
Replies: 2 comments 2 replies
-
shouldn't the |
Beta Was this translation helpful? Give feedback.
0 replies
-
Ok, I figured out that socket.read() won't execute until the socket is closed - that's why about 70 seconds pass because eventually the server closes the connections and only then am I able to read data from the socket. Is there any way to read data from the socket while the connection is still open? According to the keep-alive logic, I doesn't want to close it. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi!
I'm programming ESP32 using MicroPython and I I have encountered a problem with sending a POST request to the server using the urequest library. I have noticed that the communication speed is not stable and also always at a minimum of 1500ms and often takes up to 3000-5000ms. I need to send a POST request with json content, in response to this POST I also get a json from the server which I need to process on the device. I wanted this communication to be as fast as possible, so because I noticed such delays I stated that I would try sending a post with the header connection: keep-alive. But unfortunately it's not as easy as I thought and I don't even know if I can do it in MicroPython.
After adding some debugging logs, I came to the conclusion that this part of the code in urequest takes the most time:
if proto == "https:":'
context = tls.SSLContext(tls.PROTOCOL_TLS_CLIENT)
context.verify_mode = tls.CERT_NONE
s = context.wrap_socket(s, server_hostname=host)
and precisely the execution of the wrap_socket takes about 1000ms. That's why I concluded that maybe a keep-alive connection implementation would solve this problem.
I was fairly successful in getting a response from the server with the data, but there was a problem when trying response.json(). I had to wait about 70 seconds before the device parsed the response into json.
Looking further into the cause of the delay, I added a short code with logs and slightly changed the urequest implementation:
In addition, I have also simplified the request method to suit only my needs, added debugging logs and I added some code to support a keep-alive connection as far as MicroPython is concerned:
And then I noticed in the REPL:
As you can see, the device waited 60-70 seconds to execute socket.read(4096). So something must have been blocking the socket and this caused such a long delay in processing the response.
I would add that when I send the Connection: close header there is absolutely no problem with reading data from the socket.
My question is what could be causing this socket to block and am I even able to handle keep-alive POST requests in MicroPython? And if not, is there any other way of communicating with the server so that it is practically instant (I would expect the communication speed to stabilise and go below 1000ms, and preferably as quick as possible).
Thank you in advance for your feedback.
Beta Was this translation helpful? Give feedback.
All reactions