Cannot loop send() when trying to send large data in https_client sample on nRF9160

[OYAMA YUKIO]

Hi everyone,

I want to send large data with https protocol.

I edited the https_client sample split the data and looped send() for sending the large data.

But when I did send() once, I got error 128. Did the socket close by itself?

After I run send() once, I run close() -> tls_setup() ->connect() again. Then I can do send() again.

This is very time consuming, in a single loop, reconnecting takes 2 or 3 seconds in my environment. So I need a different solution.

Is it possible to loop send() continuously with the socket open? In the past, there have been similar case with the http protocol, but it seems that closing the socket with every send() is the solution.

https://devzone.nordicsemi.com/f/nordic-q-a/46086/nrf9160-dk-http-post-to-my-webserver

Is this still not improving? If I can send quickly even if I close the socket, it may be a solution.

HW:nRF9160DK

FW:modem v1.3.1

SDK v1.9.1

My LTE connection is LTE-M.

Best Regards,

Yukio Oyama

[Einarh]

Hi

Ok I misunderstood then, It's very possible that the same approach could work for https.

it could be that you just need to put a wait after each send for it to work.

Based on how data is sent in the https_client example I would expect this solution to work, you might just be overflowing the modem with packets when you're not waiting.

Let me know if you're still having problems.

-Einar

[OYAMA YUKIO]

Hi Einar-san,

Can I know a modem overflow? Or can I know that the packet has been sent?

Is it closed in the modem library?

Best Regards,

Yukio Oyama

[Einarh]

Hi

There is the AT monitor library which can handle AT notifications from the modem. It would probably be possible to receive a notification when a packet is sent by using this library.

There is also a function in the modem library that can give you information on the TX memory region, maybe that could be useful.

-Einar

[OYAMA YUKIO]

Hi Einar-san,

I was able to repeat Send() over 4KB by inserting a wait after Send().

However, it seems that the required waiting time differs depending on the sending data size. My sending data size is not fixed, it is dangerous to set the waiting time to a fixed value.

Can I receive AT notifications after using send()?

Or can it be received only when using the AT command with nrf_modem_at_cmd() etc.? If the AT command is required, does the chunk mode of AT#XHTTPCREQ deal with the buffer problem for repeated sending without any countermeasure? 

Is there an example of AT command execution in chunk mode? It helps me when I change the way suddenly,

Best Regards,

Yukio Oyama

[OYAMA YUKIO]

Hi Einar-san,

I haven't answered the previous question, but I have additional questions.

I was focusing on send() to send large data quickly, but I found that recv() also takes time.

When I run recv(), it takes 5-7 seconds to respond.

Looking at the receive buffer, the arrival of data by recv() is fast enough that I think the time extension to the disconnect operation.

I don't expect a disconnect with recv() because the server is keep-alive, but you said the disconnect after recv() was fine.

However, I feel that the time it takes to disconnect is long.(5-7 seconds)

Is this correct? Or is it extended with some error due to an unexpected disconnection?

If due to an error, is there a function that actively disconnects to avoid the error and reduce its time?

Best Regards,

Yukio Oyama