Guidelines and Notes
These guidelines are our advice and recommendations on how to handle
various issues involved in client development to ensure that the client does
not violate our policies.
- System Startup and DHCP Leases
- Clients should store the IP in some form of permanent storage,
so that restarting the system (for software clients) or power
cycling the device (for hardware clients) does not cause the client
to update unless the IP is changed. Since IPs rarely change on
DHCP lease renewals, clients must not update every time a DHCP lease
is renewed. Instead they must check the new IP and determine if it
differs from the old IP before updating.
- DNS Queries
- Clients should not perform DNS queries to determine whether it
is necessary to update. The danger is that the ISP's DNS server
will be caching the old IP for a few minutes, leading the client
to conclude the update failed and causing a loop.
- HTTP Headers
- The HTTP headers returned may be status 200 (OK), 401
(Authorization Required) or 500 (Internal Server Error). The
response body should be parsed for return codes no matter what this
status is; a 911 return code will most likely have a HTTP status
500. The HTTP status will not indicate any particular message. Rely on the
return codes instead.
- User Input
- Users need to enter a username and password, each up to 24 characters long.
They will also enter a list of hostnames to be updated.
It is important that the single hostname field is long enough (100-200 characters).
- WebHop Hosts
- As noted on the update syntax page, updates for WebHop hosts are ignored.