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

Hello

Looking at the https client sample, it looks like the code is supposed to support sending multiple packets before closing the socket.

I assume the changes you've made is to limit how many bytes you're allowed to send in each packet? Can you show me the exact changes you've made to the sample?

Best regards,

Einar

Hello Einar-san,

This is the minimum set with errors. (Some APN information was hidden.)

To find the cause, I searched for the smallest change where the error occurred. When sending twice (not loop), an error will occur on the second sending.

This may be due to server behavior rather than device, but I'm not familiar with either.

If a socket has been a timeout from open or access, can it be controlled by a parameter in the code?

In my experiment, send_buff [] is fixed and small in size. Finally, in my project I want to split the image file every 2KB (or less) and upload it by looping the send() .

Best Regards,

Yukio Oyama

Hi

The size of packets it is possible to send is ultimately limited by available RAM in the modem. This might be more than 2KB depending on your application, but I would still recommend staying within the documented data size limits to guarantee your application will work as you expect.

Looping send() before calling recv() should work for any buffer size you are able to send though.

-Einar

Hi Einar-san,

I repeated send() before recv(). However, error 95 occurred when the total data size exceeded around 4KB.

One transmission size -> Number of repetitions until an error occurs (total size)

429byte ->11times(all:4719byte)

685byte ->8times(all:5480byte)

1201byte ->4times(all:4804byte)

It seems to cause errors when it exceeds around 4.7KB.

Is the modem storing data without sending it every send()? Or, does it cause an error if the code repeats send() faster than the modem send the data?

In the former case, is the only solution is to close the socket?

In the latter case, is there a way to check the status of the modem before to repeat send()?

Or is there any other cause and solution?

The solution doesn't stick to repeating Send (). I want to send large data quickly.

Best Regards,

Yukio Oyama

Hm it seems you are correct, using https it looks like the modem will send all the data at once when you're done queueing data to send and call recv.

You might want to consider using websockets or something similar instead of https requests unless https requests are a crucial part of your application.

If you have to use https requests then it seems like you'll have to close the socket each time.

-Einar

Hi Einar-san,

In my application, https is more flexible because the connection destination is not fixed.

In the thread below, he created a blocking send and put a wait after send(). And it succeeds in repeating send(). Is this logical as a solution?

https://devzone.nordicsemi.com/f/nordic-q-a/51336/need-the-nrf9160-example-to-transfer-large-data-by-tcp

On the other hand, I was looking for a quick way to reconnect instead of repeating send ().

I'm sorry I'm not familiar with network connections.

Looking at the thread below, does caching the session make it easier to resume the session?

https://devzone.nordicsemi.com/f/nordic-q-a/55335/dtls-session-resumption-on-nrf9160-modem-fw-v1-1-0

But it seems that it can only be used with nrf_setsockopt().

Can't I cache the session with setsockopt()? Can I change setsockopt() to nrf_setsockopt()?

And does it help me?

Best Regards,

Yukio Oyama

Yes, if using TCP is an option for your application, then something like in the first thread you linked could be a good solution I believe.

If you want to send large data I would choose a protocol that allows this without having to reconnect after each packet, and TCP is a good option for this.

-Einar

Yes, if using TCP is an option for your application, then something like in the first thread you linked could be a good solution I believe.

If you want to send large data I would choose a protocol that allows this without having to reconnect after each packet, and TCP is a good option for this.

-Einar

Hi Einar-san,

The thread quoted uses TCP, but I don't want to use TCP. I wanted to know if blocking transmissions and wait inserts are effective.

Do you think these are logically effective in HTTPS with nRF9160?

Or do you think the only solution is to leave HTTPS and use a different protocol? Is it a difficult problem to send sliced data continuously using HTTPS with nRF9160?

Best Regards,

Yukio Oyama

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

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

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

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