Waiting for internet connectivity with Nerves

t0mh

I’m building a Nerves application that requires a handshake on boot (or close to) over the network, what’s the best way to wait for a Network connection before attempting to make a network request?

I can see from the VintageNet docs you can look up the status of a specific interface, but the application will be deployed onto devices with eth0 or wlan0 connections - is there a way to generalise this lookup?

Also, any direction on how to implement this would be appreciated, I’m still pretty new to using Elixir and getting my head round recursion. For example, is it best to block to block while a network connection is found or to run a separate process that waits in the background and then alerts other processes to a working connection? I suspect for my use case it would be best to block until we have a connection, but I’m wary this might not be the “Elixir” way of doing things.

Many thanks.

4 comments

/nerves #vintage_net

1 1451 4

2020-07-15 09:15:38 UTC

Showing Posts 1 to 4

Show Best Posts
Show All (oldest first)
Show All (newest first)

LostKobrakai

Subscribe to vintage_net events and wait for some network to come online. Then start doing your work (given you stay online).

Post #1

t0mh

Would it be acceptable to add some modules to a dynamic supervisor when the network comes online?

Post #2

fhunleth

Co-author of Nerves

To add to the comment about subscribing to vintage_net events, quite a few libraries choose to repeatedly try to connect whenever they’re disconnected from a server. For example, MQTT client libraries like Tortoise and the Phoenix channel client libraries like PhoenixClient and phoenix_gen_socket_client take this approach.

Losing a connection to a server isn’t a Nerves-specific issue. One advantage to polling is that your code doesn’t carry a dependency on vintage_net and therefore can be developed and run outside of a Nerves device.

The disadvantage of polling is that it can take your code a long time to connect to the server after it boots. A way around this is to register for interface up notifications from vintage_net and have those events “kick” your code to retry connecting to the server immediately.

Regarding your question about using a dynamic supervisor, I feel like that there might be some nuance in your use case that pushes you to one solution or another. You’ll have a GenServer that tries to connect. Once it connects, though, it could either hand off connection session to another GenServer or manage it itself. Some people like the state machine aspect of doing this in one place, but there’s a point where I think the code gets too complicated.

Post #3

t0mh

Thank you both for your responses. The polling technique seems to be the simplest and most error-resistance. Once polling was implemented, I felt like using a Dynamic Supervisor wasn’t needed anymore as the GenServers would manage their own connections.

One further question; Is there any way to unit test the polling behaviour reliably?

Post #4

— All posts loaded —