Dynamic loading of object code is a feature many operating systems provide. In fact, Java supports it across platforms and directly in its specification. It is a vary powerful tool for application configuration, upgrading, and building extensible programs.

A company desires to build an extension framework for their latest line of products. A key piece of this framework is a mechanism to find and retrieve a piece of object code over the network and load it into its running executable using dynamic loading. The first piece that must be built is the DODS (Dynamic Object Directory Service) server. This server has the main function of taking client requests for certain dynamic objects and returning a (machine,port,pathname) combination where the object can be retrieved from. The server is to be an iterative UDP server.

The client will send a UDP request to a machine and port. The request will have the following format:

Bytes:  2     Var    1  Var   1  Var   1
      +---+---------+-+------+-+------+-+
      |Ver| ObjName |0| Mach |0| Lang |0|
      +---+---------+-+------+-+------+-+

The DODS server will respond to each request with a UDP datagram back to the client which follows the format below. If the object can not be found, the IP is set to 0.0.0.0, the Port set to 0, and Pathname is set to "NotFound".

Bytes:  2     Var    1  Var   1  Var   1  4   1   2    1   Var      1
      +---+---------+-+------+-+------+-+----+-+------+-+----------+-+
      |Ver| ObjName |0| Mach |0| Lang |0| IP |0| Port |0| Pathname |0|
      +---+---------+-+------+-+------+-+----+-+------+-+----------+-+

The DODS server is configured by a configuration file. The file has a very simple format where each line represents an entry of this form: ObjName Mach Lang IP Port Pathname. Here is an example couple entries:

MyGUI Sun/Solaris2.5.1 C++/SunC++4.2 157.182.194.39 2500 /tftpboot/MyGUI.so
MyGUIJ Intel/WinNT4.0 Java/JDK1.1.4 157.182.194.39 2500 /tftpboot/MyGUIJ.class

Your DODS server must take a port argument for the port it must bind to as well as a filename for the configuration file. It must print out when a request comes in and the ObjName, Mach, and Lang information from the request. When it sends a response, it must print out the information that it places in the response.

Example

$ dodsd 2300 dods.conf

should produce output similar to this:

dodsd bound to UDP port 2300
Reading configuration file: dods.conf
Ready......
Request: 157.182.194.28.45000: MyGUIJ Intel/WinNT4.0 Java/JDK1.1.4
Response: to 157.182.194.28.45000: MyGUIJ Intel/WinNT4.0 Java/JDK1.1.4 
	is at 157.182.194.39.2500 in /tftpboot/MyGUIJ.class   

• Client for debugging. A client is in ~cs268/dodsc
• Example config file. An example file is in ~cs268/DODS/dods.conf
• A working DODS server is on naur on port 2300 running as cs268. You can try it out by using the client with the following command: dodsc -d naur 2300 For object name, etc. use something from the config file. Such as object name of MyGUIJ, mach of Intel/WinNT4.0, and lang of Java/JDK1.1.4. You can also specify these on the command line using the -o, -l, and -m options. You will be prompted for them if they are not supplied.

Extra Credit

For extra credit, provide a simple DODS client that takes as its arguments a DODS server address and port as well as ObjName, Mach, and Lang. The client must retransmit a request until it gets a response or it retransmits 10 times. After the 10nth retransmit, the client must print an error and exit.

For extra credit, provide Ver 1 of DODS that supports access control through passcodes in the configuration file (added to each line). The passcode is added to the end of the request. The passcode is NOT sent in the response. If an incorrect passwode is received, the Pathname in the response is set to "WrongPasscode" and IP and Port are set to 0.