Various clarifications for NetworkInterface state and connection #957
Conversation
|
@kjbracey-arm Please review the content. @yogpan01 @teetak01 @anttiylitokola @JanneKiiskila Please review from Client point of view. I have seen that the Client has some assumption on undocumented behaviour of The content here might affect how the non-blocking operations and network status listeners are going to be implemented. Thanks. |
AnotherButler
requested review from
yogpan01,
teetak01,
anttiylitokola and
JanneKiiskila
|
|
||
| The interface handles all state changes itself between `Connecting`, `Local connectivity` and `Global route found`. Calling `NetworkInterface::connect()` might return when either local or global connectivity states are reached. This depends on the connectivity. For example, Ethernet and Wi-Fi interfaces return when global connectivity is reached. 6LoWPAN-based mesh networks depend on the standard you're using. 6LoWPAN-ND returns when it connects to a border router that provides global connection. The thread returns when you create a local mesh network and may later get global connection when it finds a border router. | ||
| The interface handles all state changes itself between `Connecting`, `Local connectivity` and `Global route found`. Calling `NetworkInterface::connect()` might return when either local or global connectivity states are reached. This depends on the connectivity. For example, Ethernet and Wi-Fi interfaces return when global connectivity is reached. 6LoWPAN-based mesh networks depend on the standard you're using. The `LoWPANNDInterface` returns from `connect()` call when it connects to a border router that provides global connection. The `ThreadInterface` returns from `connect()` call when it joins a local mesh network. It may later get global connection when it finds a border router. |
There was a problem hiding this comment.
Better some questions though.
"might return" when might it not return?
"This depends on the connectivity" I can assume this is referring to WiFi, Ethernet, 6LoWPAN, Cellular, etc.
However does "connectivity" correlate to a particular network layer and would it be useful to reference said layer?
There was a problem hiding this comment.
To answer my own connectivity question. No? Because connectivity can sprawl multiple layers and this is TCP/IP.
There was a problem hiding this comment.
Yes.
"Connectivity" here refers to L2/L3 combination. In more specifically, it refers to which NetworkInterface subclass you have selected as those examples show.
|
Code dependency merged in. |
|
@SeppoTakalo Are all of the reviewers who have not yet reviewed this optional, or are any mandatory? |
|
@AnotherButler Those are optional. For me, it is enough that Kevin reviewed from engineering point of view. Then I would like someone from Client side, and I tagged 4 persons. Teemu reviewed, so I think this is OK now. |
|
|
||
| When using two network interfaces where both use the same IP stacks, there are limitations. Both IP stacks, LwIP and Nanostack, are build using assumption that there is only one active interface. | ||
| For the Mbed OS 5.12, the LwIP routing core was modified to support multiple active interfaces, but it has its own limitations as well. When you have more than one active interfaces in LwIP, only one is the default, which all the outgoing traffic flows through. | ||
| If you need to force the traffic to only one of the interface, you need to use `Socket::setsockopt(NSAPI_SOCKET, NSAPI_BIND_TO_DEVICE, <interface name>, <interface name length>)` to bind the socket into one interface. Interface name can get fetched from `NetworkInterface::get_interface_name()` call. |
There was a problem hiding this comment.
Is there PR for NetworkInterface::get_interface_name()?
Edit file, mostly to remove references to "new" for easier maintenance and to update example to latest version.
| @@ -2,7 +2,7 @@ | |||
|
|
|||
| This interface informs you about connection state changes asynchronously. Providing a method to register a callback function to a socket accomplishes this. Each time the network interface's state changes, it triggers the callback. | |||
|
|
|||
| <span class="images"><span>Network states</span></span> | |||
| <span class="images"><span>Network states</span></span> | |||
There was a problem hiding this comment.
I don't know if this format will render nicely, but I'm interested to try it and see.
Edit file, mostly for active voice and minor wording changes.
|
Please review my edits to make sure I didn't accidentally change the meaning of anything. |
"usually reconnects" -> "reconnects" because it is not optional. "active interface is active in ..." -> "interface is active in.."
|
Edits look OK. Now it makes more sense. |
|
Thanks, @SeppoTakalo |
This PR addresses various issues reported:
It should clarify now all network interface state changes, and how different interfaces might implement those. It also addresses how you should use the interface asynchronously(non-blocking) and how return values differ there.
The image supplied should replace existing diagram from here: https://s3-us-west-2.amazonaws.com/mbed-os-docs-images/NetworkinterfaceStates.png
Some of the bundled changes only apply to Mbed OS 5.12, so this is targeting it.
Also, I have code-dependency to ARMmbed/mbed-os#9387 which should be merged soon.
Fixes #936