DDNS Implementation Details

Source Distribution

The only source distributed for this project is an application, nslookup, and a system service, HTTPDService:

• nslookup.java
• HTTPDService.java
  Note: The OS I'm running has been modified from the Project 3 distribution, so you'll have to do a bit of porting. Change implements OSLoadableService to Project 3's extends RPCCallable, and public String loadablename() to public String servicename() to compile with your code.
• NanoHTTPD.java

To allow a browser to talk to one of your services, you need to do two things:

1. Declare the service's Java class as implementing the HTTPProvider interface. For example,

   public class DDNSService extends RPCCallable implements HTTPProvider
   

2. Implement one routine:

     /**
        * Serves web pages.  The 0th element of uriArray is always null.
        * The next element names this service ("ddnsresolver").  The optional third
        * component is a name to be resolved before dumping the cache.
        */
       @Override
       public String httpServe(String[] uriArray) {...}
   

   The returned string is what will displayed by the browser. The argument is the URL parsed

Threads

This isn't a course about concurrent programming, and the course that is a course about concurrent programming isn't a pre-req to this course. Despite that, threads are inevitable in networked code. You won't be graded on whether your code handles threads 100% correctly. On the other hand, errors can cause occasional crashses 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 zone (the name tree you manage) and your resolver cache. You should synchronize reads and writes to those structures, as in

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

Config files

The overall code architecture has a goal that a single source code base can be installed on multiple devices with modification, but that each can be configured somewhat differently by using different config files. In my implementation, I include in the config file such things as the definition of the names to be contained in the zone (if a name server will run on the device the config file is for). I also include the host name for the device and the location of the root name server.

You can solve this problem however you want. A technique that avoids requiring source code modifications is "the right way to do it," though.

Your config files should go in project OS, as they were in the Project 3 source distribution.

How We'll Test Your Code

The goal is to take your code, add to it an application (like Echo and Ping) that we'll write to test your DDNS implementation, and then run it. Since we haven't required any particular application API, though, this will only sometimes work. We'll deal with resolving any issues, but you can help out by explaining in the report your turn in anything unexpected: anything that doesn't work in your Project 4 the way they worked in the Project 3 source distribution. (For example, if you no longer launch the AppManager to start your code, you should tell us that.)

Obtaining a Zone

Each group should take ownership of some zone rooted at xxxx.cse461 for some xxxx. As a side effect, this will also create name xxxx.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.cse461 and the A record for xxx.cse461.www., both maintained by the root.

You control the passwords for all nodes created in your zone.

Expect there to be a multi-hour delay between when you send the request for a zone and actually having it set up.