Re: [Geopriv] LIS discovery implementation thoughts

One additional note: Our client is not technically compliant with RFC 5986, since it doesn't validate the URI with a HELD request:
"
   A Device that discovers a LIS URI MUST attempt to verify that the LIS
   is able to provide location information.  For the HELD protocol, the
   Device verifies the URI by making a location request to the LIS.  
"

--Richard

On Jan 13, 2011, at 11:45 PM, Richard L. Barnes wrote:

> Hey all,
> 
> Just wanted to share some impressions of the LIS discovery process, including NAT traversal, based on our experience implementing this function in the igtk project [1].  (Note: The techniques here haven't yet been merged into the sourceforge version.)
> 
> The basic flow-chart in RFC 5986 is pretty easy to implement, although it wasn't really clear what to do for step (3), "Check URI", beyond verifying that it's a well-formed URI.  In pseudo-code, we ended up with something like this:
> 
> foreach (NetworkInterface iface) {
>    DomainIterator it(iface);
>    while (it.hasNext()) {
>        string lisUri = performDdds(it.next());
> 	if (valid(lisUri)) { return lisUri; }
>    }
> }
> 
> Here the DomainIterator supplies the following domains, if they are available:
> 1. Option 213 [NB: Not DHCPv6 capable]
> 2. Option 15
> 
> The DomainIterator construct also allows us to easily extend the process to support NAT traversal.  If neither of the above options works, the DomainIterator looks at the IP address for the interface, and if it's private (any of the IANA reserved ranges [2]), then it does a STUN request to find a public address.  Using either the interface address or the STUN address, it then provides the following domains:
> 3. The reverse domain
> 4. The reverse domain with the first label dropped
> 5. The reverse domain with the first two labels dropped 
> 
> The entire LIS discovery service, which listens for network interface changes and emits alerts when it finds a new LIS URI, required 584 lines of C++.  A very basic STUN client was another 293.
> 
> So in a nutshell, extending a client from RFC 5986 to draft-thomson-geopriv-res-gw-lis-discovery was pretty trivial, just a matter of adding a few domains to the search list.  We hope to have the code posted to the igtk site soon; if you're interested in an advance copy, let me know and I can send you an interim snapshot.
> 
> --Richard
> 
> 
> [1] <http://igtk.sourceforge.net/>
> [2] <http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv