How to properly handle the case wiced_tcp_send_buffer() return WICED_WOULD_BLOCK?

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

cross mob
Anonymous
Not applicable

Hi,

I'm debugging a tcp transfer test that the receiver does not receive data correctly.

Then I found wiced_tcp_send_buffer() may return 16 (WICED_WOULD_BLOCK)

sometimes when test transfering data.

What is the proper way to handle the WICED_WOULD_BLOCK case?

WIll the wiced_tcp_send_buffer() call send out the data eventually even if it returns WICED_WOULD_BLOCK?

If yes, how can I tell if the send out data is done.

If not, should I call wiced_tcp_send_buffer() again to resend the data?

(My test is on FreeRTOS+LwIP with SDK-3.1.0-beta1)

Thanks.

0 Likes
5 Replies
Anonymous
Not applicable

hi,

Here is my understanding of this problem:

The logic of my code is:

while (has_remainding_data) {

        copy data to a temp_buffer

        wiced_tcp_send_buffer(socket, temp_buffer, data_length);

}

So if wiced_tcp_send_buffer() returns WICED_WOULD_BLOCK, it looks like it

will be handled latter.

However, in next while loop iteration I copy data to override temp_buffer

to send more data. And then when the code to handle WICED_WOULD_BLOCK is

executed it actually copy the overrided data in the temp_buffer.

So the result is the remote side received wrong data.

It seems the issue can be avoid if I check return value of

wiced_tcp_send_buffer() and add a small delay if the return value is WICED_WOULD_BLOCK.

But this is a non-safe code, we don't know how much delay time is required.

Any suggestion to handle this issue?

Thanks.

0 Likes
Anonymous
Not applicable

Hi,

Just wondering is anyone can answer this question?

0 Likes
Anonymous
Not applicable

Your understanding of WICED_WOULD_BLOCK is incorrect.

WICED_WOULD_BLOCK maps to ERR_WOULDBLOCK from the BSD sockets layer.

This means that if you issue a call to a non-block socket and if that socket would block due to the action you are performing, the sockets layer would return this error.

In your code, you need to retry the operation. This return does not mean the operation has been queued and will complete asynchronously.

So the best way to handle this would be that you sleep for a short period of time and then retry your send operation.

Anonymous
Not applicable

Hi nsankar,

a resend does not work well if the buffer_length is large than available_space

(at least for LwIP build).

In wiced_tcp_send_buffer() (WICED/network/LwIP/WICED/tcpip.c),

If buffer_length > available_space, it's possible some wiced_tcp_send_packet()

calls are success before return error from wiced_tcp_send_buffer().

So the caller has no way to know which part has been sent successfully and which

part needs a resend.

Anonymous
Not applicable

Discussion is being locked. If you have any follow-up, please start a new discussion.

0 Likes