Public-Mesh-Research-Report.md

@@ -330,7 +330,7 @@ However, given the use cases that are described in the Bluetooth Mesh docs (eg s
 
 In short, Bluetooth Mesh doesn't appear to be usable for creating smartphone-based mesh networks at present, and seems unlikely to become usable for that purpose in future.
 
-## Wi-Fi
+## LAN Multicast
 
 Devices that are connected to the same LAN may be able to discover each other using IP multicast and then connect to each other using TCP or UDP.
 
@@ -340,18 +340,18 @@ Discovery can be achieved using a variety of protocols, for example:
 * [Universal Plug and Play (UPnP)](https://en.wikipedia.org/wiki/Universal_Plug_and_Play)
 * [Local Service Discovery (LSD)](https://www.bittorrent.org/beps/bep_0014.html)
 
-On Android, the Network Service Discovery (NSD) API provides service advertising and discovery on the local network via mDNS/DNS-SD and UPnP. The mDNS/DNS-SD API can interoperate with Apple's Bonjour API, which could be useful for cross-platform communication.
-
-(Android's Wi-Fi Direct API also provides service discovery and advertising via mDNS/DNS-SD and UPnP. Wi-Fi Direct service discovery does not interoperate with NSD, but it may simplify the implementation of higher layers if the same service definitions can be used for LAN and Wi-Fi Direct transports.)
-
 ### Multicast Issues
 
 Wi-Fi networks with a single access point typically support IP multicast and allow client devices to communicate with each other. However, some Wi-Fi networks, especially large networks with multiple access points, may not allow this. Client devices must use trial and error to find our whether multicast and connections between clients are allowed on a given network.
 
-Some Android devices cannot receive multicast packets at all, or can only receive them while the device is awake. Some devices can receive multicast packets via the NSD API, but not directly via multicast sockets, making NSD more useful than other protocols such as LSD on those devices.
+Some Android devices cannot receive multicast packets at all, or can only receive them while the device is awake. Again, this can only be discovered through trial and error on a given device.
 
 ### Network Service Discovery (NSD)
 
+Android's Network Service Discovery (NSD) API provides service advertising and discovery on the local network via mDNS and DNS-SD. The NSD API can interoperate with Apple's Bonjour API, which could be useful for cross-platform communication.
+
+(Android's Wi-Fi Direct API also provides service discovery and advertising via mDNS/DNS-SD, as well as UPnP. Wi-Fi Direct service discovery doesn't interoperate with NSD, but it may simplify the implementation of higher layers if the same service definitions can be used for LAN and Wi-Fi Direct transports.)
+
 #### Peer Advertisement
 
 <https://developer.android.com/training/connect-devices-wirelessly/nsd#register>
@@ -366,23 +366,27 @@ Some Android devices cannot receive multicast packets at all, or can only receiv
 
 #### Notes
 
-- It's probably worth noting that NSD is also a special case for Android apps running on ChromeOS: apps can't generally make or receive connections via the LAN, except in the case of outgoing connections to services discovered via NSD. See [briar#1362](https://code.briarproject.org/briar/briar/-/issues/1362).
-- This comment suggests that NSD service resolution will fail for network interfaces that don't have an associated Network instance:
+Some devices (eg Huawei P8 Lite 2015 and 2017) can receive multicast packets via the NSD API, but not directly via multicast sockets, making NSD more useful than LSD on these devices.
 
+NSD is also a special case for Android apps running on ChromeOS: apps can't generally make or receive connections via the LAN, except in the case of outgoing connections to services discovered via NSD. See [briar#1362](https://code.briarproject.org/briar/briar/-/issues/1362).
+
+The following comment suggests that NSD service resolution will fail for network interfaces that don't have an associated Network instance:   
 <https://cs.android.com/android/platform/superproject/+/master:packages/modules/Connectivity/service-t/src/com/android/server/NsdService.java;drc=b45a2ea782074944f79fc388df20b06e01f265f7;l=576>
 
-- On at least some devices, NSD works when using a WFD legacy mode hotspot. Tested with Samsung A21s as hotspot, Nokia 1.3 as client and vice versa. Tested with the `wifi-direct-and-nsd` branch.
+On at least some devices, NSD works when the LAN is a Wi-Fi Direct legacy mode access point. Tested with Samsung A21s as access point, Nokia 1.3 as client and vice versa. Tested with the `wifi-direct-and-nsd` branch.
+
+#### Service Resolution Issues
 
-- When discovering services via NSD, one needs to resolve each service found to find out IP address, port etc.
+When discovering services via NSD, one needs to resolve a discovered service to find out its current IP address and port. `NsdManager` has a method `resolveService()` for this. Only one service can be resolved at a time: an error with code `FAILURE_ALREADY_ACTIVE` will appear when a second simultaneous resolve request is submitted. Hence it is important not to call that method right away when new services have been discovered. Instead, a queue needs to be maintained and worked on one by one. Resolving a service can succeed or fail, and after either event it should be possible to resolve the next service.
 
-- NsdManager has a method `resolveService()` for this. Only one service can be resolved at a time, an error with code `FAILURE_ALREADY_ACTIVE` will appear when a second simultaneous resolve request is submitted. Hence it is important not to call that method right away when new services have been discovered, instead a queue needs to be maintained and worked on one by one. Resolving a service can succeed or fail and after both events, it should be possible to resolve the next service. It seems however, that sometimes resolving neither succeeds nor fails, but instead we receive a service lost event. We don't get any updates on the resolving request afterwards, but we also cannot submit a new resolve request afterwards, they will still fail with a `FAILURE_ALREADY_ACTIVE` error. Even restarting the service discovery entirely did not seem to help.
+It seems, however, that sometimes resolving neither succeeds nor fails, but instead we receive a service lost event. We don't get any updates on the resolving request afterwards, but we also cannot submit a new resolve request afterwards: they will still fail with a `FAILURE_ALREADY_ACTIVE` error. Even restarting service discovery entirely doesn't seem to help.
 
-- The `lan-service-discovery-nsd-no-resolution` branch encodes the IP address in the NSD service name, allowing us to skip the buggy resolution step.
+The `lan-service-discovery-nsd-no-resolution` branch encodes the IP address in the NSD service name, allowing us to skip the buggy resolution step.
     
-	- This means we can't advertise attributes, unless we encode them in the service name along with the address or fetch them separately via unicast. This (abandoned) library implements the latter approach to work around the empty attributes map issue mentioned above: 
+This means we can't advertise attributes, unless we encode them in the service name along with the address, or fetch them separately via unicast. This (abandoned) library implements the latter approach to work around the empty attributes map issue mentioned above:   
 <https://github.com/youviewtv/tinydnssd>
 
-	- Alternatively we could implement our own unicast protocol for fetching attributes, while still using NSD for the multicast part, to benefit from the special treatment it seems to get on some devices.
+Alternatively we could implement our own unicast protocol for fetching attributes, while still using NSD for the multicast part, to benefit from the special treatment it seems to get on some devices.
 
 ### Local Service Discovery (LSD)
 
@@ -404,6 +408,8 @@ Once peers are discovered, a normal TCP connection can be made with the `HOST:PO
 
 #### Notes
 
+## Wi-Fi
+
 ### Wi-Fi Client
 
 #### Peer Advertisement