Handling network dropouts with HTTP_client library

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ViRa_3651841
Level 1
Level 1
First like given

Hi all,

We're working on a project which makes use of the HTTP_client library, and noticing some strange behavior specifically with unstable networks. Using WICED 6.2 - ThreadX with NetXDuo. An unstable network is simulated by having the WICED device connect to a phone hotspot, then quickly toggling the phone hotspot off and on.

We have written some logic in the firmware to maintain the HTTP connection and handle error returns, and for the most part this is all working smoothly. However, about 10% of the time, there is some strange behavior that our logic isn't able to handle. The two major things I've noticed are below:

A)

1. in the middle of an https_request_write() call, if the network is interrupted, an error is returned.

2. HTTP_disconnect is explicitly called, and the client is deinited

3. HTTP connect is requested

4. In the call to wiced_tcp_connect(), the nx_tcp_client_socket_bind() function returns success. Shortly after, the nxd_tcp_client_socket_connect() function returns an error code 0x38 (56) NX_NOT_CONNECTED.

5. Again, http_disconnect is called and the client is deinited

6. http_connect is requested, and the same error occurs. This repeats forever.

7. Once in this state, any MQTT connections requested also fail

B)

1. in the middle of an https_request_write() call, if the network is interrupted, an error is returned.

2. HTTP_disconnect is explicitly called, and the client is deinited

3. HTTP connect is requested

4. This time, the connect happens successfully. So the firmware begins to write to the request again using http_request_write().

5. This leads to wiced_tcp_stream_write(), and when send_packet is set to true, the call is made to wiced_tcp_send_packet()

6. In wiced_tcp_send_packet(), the call is made to network_tcp_send_packet(), which in turn calls nx_tcp_socket_send().

7. At this point, nx_tcp_socket_send() returns 0x01 NX_NO_PACKET after a few seconds.

8. Detecting this error, http is explicitly disconnected and the client is deinited

9. HTTP connect is requested again, and is again successful.

10. Again, as soon as we start writing to the http request, the same error code NX_NO_PACKET is returned.

What makes this debug tough is that both the functions which error out in the scenarios above (nxd_tcp_client_socket_connect, nx_tcp_socket_send) have no source code provided through WICED. However, Microsoft did recently release the source code for their Azure RTOS (https://github.com/azure-rtos/netxduo.git). Browing through both these functions (nxd_tcp_client_socket_connect(), nx_tcp_socket_send_internal()), the only way those respective error codes could have been returned is when the code pathway leads to the line "return(_tx_thread_current_ptr -> tx_thread_suspend_status);"

Would highly appreciate any ideas or insights here. I think - important to note - for the most part, network issues during http requests are handled and recovered fine in the firmware. However, there are instances where we run into one of the above scenarios where our firmware can't really do much else without understanding why those errors are being returned.

Thanks in advance.

0 Likes
1 Reply
Aditi_B
Moderator
Moderator
Moderator
500 replies posted 5 questions asked 250 replies posted

Hi,

Could you provide us with the application code that you have used for the above project to better understand the issue? If the application code is confidential and sharing isn't possible, you can provide us the code example through the message option.

Thanks

0 Likes