• State Not Answered
  • Replies 21 replies
  • Subscribers 26 subscribers
  • Views 759 views
  • Users 0 members are here
Attachments (3) Download All
Nordic Case Info
  • Case ID: 288293
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs

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

user113109

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

  • 0 in reply to user113109
    yukio oyama said:
    In my code, it takes about 35 seconds to send a 30KB file, so I consider the send() calling to take longer than the 200ms wait time.
    yukio oyama said:

    Today, I used the Modem shell App and iperf3 to check the effective speed of the uplink in my environment.

    It was 100K ~ 180Kbps

    This seems strange to me, it would be interesting to know what in send() is taking so much time, is it waiting for an answer from the server? or a timeout?

    yukio oyama said:

    I think it could be based on "\zephyr\samples\net\sockets\http_client".

    Is this any difference compared to "\nrf\samples\nrf9160\https_client"?

    Yes they are different, Zephyr's sample uses Zephyr's HTTP Client API, while the nRF9160 sample doesn't. From what Didrik is saying it seems like Zephyr's library is a more complete implementation, so maybe you'll have more luck with that.

    I would also recommend having a look at Zephyr's CoAP API. It has a very similar use case to HTTP, and you might find it easier to use with the nRF9160.

    Best regards,

    Einar

Related
Terms of service