NRF9160 Underlying Socket Behavior During Cellular Drops

[emh203]

Hello:

I am working on an application that uses a simple UDP socket for transmitting data.   I would like understand the zephyr BSD socket behavior when there are cellular connects/disconnects.

1.)   I my application I create a socket and then send data once a minute.      If I detect that the cellular connection has disconnected,  do I need to explicitly call close()  and then call  another open() and connect()?

In my current test firmware,  I noticed that sometimes a call to close() on an existing socket when there is no cellular connection will cause the NRF9160 to enter a weird state.    In my case, the zephyr shell thread kept working by the main thread which had the networking call appeared to be sleep/idle state forever after the close was called.

2.)  I created a simple test application where I could close() on an invalid/unused socket and could get the exact behavior from #1.    

For applications where I want to use UDP,  what is the correct order of operations when I detect a cellular connection is dropped?    I am trying to ensure that I can gracefully recover in this situation.

[emh203]

Just an updated,   I did update my code to call socket() once and then use sendto()  instead of connect()/send().       The socket does seem to persist between drops in cellular connection.      However, I still would like to understand socket behavior when the underlying cellular connection changes.   Right now we are using UDP but may also be using a TCP stream.

[Didrik Rokhaug]

Hi,

If the connection is truly lost, you will receive an error the next time you try to use the socket. After that, you should call close(), to ensure that all resources are freed.

However, you might also have shorter intervals where the device has lost it's connection to the network. In those cases, you should still be able to queue data to be sent, while the device tries to reconnect.

Best regards,

Didrik