Module: ThaliWifiInfrastructure

For the definition of this event please see module:thaliMobileNativeWrapper~discoveryAdvertisingStateUpdateEvent

This notifies the listener whenever the state of discovery or advertising changes. In module:thaliMobileNativeWrapper the equivalent of this event is fired from the native layer and then works its way through module:thaliMobileNative to module:thaliMobileNativeWrapper. But in the case of Wifi there is no native layer. Therefore if there is a call to start/stop discovery/advertising or if a network change event forces a change in status (e.g. someone turned off Wifi) then this class MUST issue this event itself. That is, it must have hooked into the start/stop methods, start/stop discovery/advertising methods, module:thaliMobileNativeWrapper.nonTCPPeerAvailabilityChangedEvent events when we are on mobile devices and module:ThaliWifiInfrastructure.networkChangedWifi when we are on desktop to figure out when status has changed and this event needs to be fired.

For the definition of this event please see module:thaliMobileNativeWrapper~discoveryAdvertisingStateUpdateEvent.

The WiFi layer MUST NOT emit this event unless we are running on Linux, OS/X or Windows. In the case that we are running on those platforms then If we are running on those platforms then blueToothLowEnergy and blueTooth MUST both return radioState set to doNotCare. Also note that these platforms don't generally support a push based way to detect WiFi state (at least not without writing native code). So for now we can use polling and something like network-scanner to give us some sense of the system's state.

This event specifies that a peer was discovered over Wi-Fi Infrastructure. Please keep in mind that IP address bindings can change randomly amongst peers and of course peers can disappear. So this should be considered more of a hint than anything else. If the peer has gone (e.g. ssdp:byebye) then both hostAddress and portNumber MUST be set to null.

Note that when sending SSDP queries we MUST use a randomly assigned address for the local UDP port as described in ctions. It is not necessary that this be the same UDP port as used in the previously mentioned function.

Open Issue: There is a pretty obvious security hole here that a bad actor could advertise a bunch of IP or DNS addresses of some innocent target on a local network in order to trigger a connection storm. Given the various limitations in place it's unclear how effective this would really be. There are things we can to ameliorate the attack including only accepting IP address that match the local network mask and also rate limiting how quickly we are willing to connect to discovered peers.