DDNS Implementation Details

Config files

You should use the following fields in your config file:

Field name	Use
net.hostname	DDNS full name of this host
ddns.rootserver	IP address of DDNS root name server
ddns.rootport	Port of DDNS root name server
ddns.nodes	A whitespace separated vector of resource record entries in the zone. Example: ddns.nodes=soa:default.uw12au.cse461.:samplePassword \ a:child.default.uw12au.cse461.:samplePassword
ddns.resolvettl	Upper bound on the number of name resolution steps
ddnsresolver.cachettl	TTL of entries in the resolver's cache, in seconds. Value 0 means "don't cache"
ddnsresolver.serverttl	Max number of distinct DDNS servers to contact before giving up
ddnsresolver.password	A password to use when registering or unregistering names

Source Distribution

The original source distribution contains skeleton files for the main classes (DDNSResolverService and DDNSService), located in the DDNS source under the Net project. (Interface files for those classes summarize their public methods more easily than scanning the full source.)

Additionally, classes are provided for DDNS exceptions and resource records, as well a utility class for manipulating DDNS full names. It's recommended that you use these, but as they are not part of the public interface their use is optional.

Threads

Threads are inevitable in networked code, but the pre-reqs for this course don't provide extensive experience with them. For that reason, you won't be graded on whether your code handles threads 100% correctly. On the other hand, errors can cause occasional crashes that are hard to reproduce. To help avoid that frustrating situation, here's one tip.

Some Java data structures are not "thread safe." This means that they can crash your application if two or more threads access them at once. You'll undoubtedly have some kind of data structure to hold your DDNS zone and your resolver cache. You should synchronize reads and writes to each of those structures, as in

   synchronized(this) {
      node = readCache(name);
   }

That, plus the fact that the load on your implementations will be very light, should be enough to avoid race related crashes.

Obtaining a Zone

Each group should take ownership of some zone rooted at xxxx.uw12au.cse461 for some xxxx. As a side effect, this will also create name xxxx.uw12au.cse461.www.

To allocate yourself a zone, send mail to me (zahorjan@cs). Include the zone name you want and the password you want. The password will apply to the NS record for xxxx.uw12au.cse461 and the A record for xxxx.uw12au.cse461.www., both maintained by the root. Expect there to be a multi-hour delay between when you send the request for a zone and actually having it set up.

To allocate yourself a zone, use this form to register a DDNS name (alias) and password. This will create an NS record for your alias, with name like <alias>.uw12au.cse461.. The password you create is required to register an address for the NS record, to point it at the DDNS server for your zone. (You control the passwords for all nodes created within your zone.) It will also create an A record with name like <alias>.uw12au.cse461.www., where you can register your HHTPD server. If you are working on a team, you can all individually create aliases, or you can share one created by any one of you.

You can edit your alias and password using the same form. It may take tens of minutes for the root DDNS server to notice your initial registration, or any subsequent edit.

General Consideration

The DDNS specification is precise about what information goes on the wire. It's fuzzy about what the receiver of that information should do with it -- we know that calling resolve() should result in name resolution, but we don't specify all details of how that works, or what to do in every case. You should keep clear that there are implementation choices, and you're free to make whatever decisions about them you want, so long as you interact with other DDNS implementations in sensible ways.