Frequently Asked Question
* Note: this section is initiated by the staff.
Recursor
Q1: Why doesn't the server have a time-out function while the recursor has one?
A1: Because it is hard to detect the time-out from the server side, as one could assume
Python never fails the server to call socket.send , although the data may not be transmitted
to the recursor successfully.
Server
Q1: How does the server decide whether it is a root server, a TLD server or an Authoritative
server?
A1: It is not always possible that a server can tell the purpose of itself, and a server has no
necessity to know its purpose. Example can be found in this comment in #976.
Q2: Will a command change the configuration file which is being supplied to a running
server?
A2: No. The changes by caused the commands are temporary. A command will temporarily
change the server's records and these changes caused the commands will be lost when the
server is shutdown. The changes will not persist if the server is restarted with the same
configuration.
Q3: If a user wants to issue a !EXIT command to the server, how can this be done, by the
recursor program? (Ref#1019)
A3: The recursor program is not designed to delivery any commands to the server.
However, any genuine TCP client is capable of sending a message to the server, e.g., maybe a
Linux program netcat or socat can do so with minimal effort.
Q4: Why does the server even need a command system? (Ref#1019)
A4: The server program is too boring if it is just a solid one-piece program that cannot be
changed after it has been started up. To make the server more hackable, commands are
here to help.
Q5: Are we only need to write test cases for the server program? (Ref#1017)
A5: Only self-testing of the server program is assessable. Note that this includes the testing
over all your self-implemented modules, if any. (And of course excludes the testing over
standard libraries).
Q6: When should the server log INVALID\n ? (Ref#1000)
A6: The server should log INVALID\n if:
The input cannot be interrupted as a complete command, AND
The input cannot be interrupted as a valid hostname.
Note that the completeness of a command only depends on its form (syntax).
E.g., A correct command name and the expected number of arguments that are separated
by Space characters. The completeness does NOT depend on the validity of the argument,
e.g. some argument is invalid.
Q7: Are we allowed to create new Python script, e.g., utils.py , which contains functions
that can be reused across different tasks? (Ref#1000)
A7: Yes. Consequently, for self-testing, we will assess the total coverage rate, including the
coverage of self-made modules that are used in server.py . The suggestion is that any new
module that server.py imports should ONLY contain functions that server.py actually
calls and uses.
Launcher
Q1: Where do the Launcher and Verifier come from?
A1: The Server needs a "single" configuration file, but such file does not always naturally
exist. Someone must be able to generate it from something. Someone is the Launcher, and
something is the master configuration file. The verifier is a checker to validate the collective
outcome of some "single" configurations is equivalent of one "master" configuration.
Q2: How to break down one "master" configuration to multiple "single" configurations?
A2: A natural way is to divide "master" by the DNS levels: Root, TLD, and Authoritative.
Q3: Does the configuration file have any naming scheme? (Ref#985)
A3: No. The server program needs a file path to a configuration file, and the launcher can
name the generated "single" configuration files randomly.
Q4: Can a launcher overwrite existing files on disk? (Ref#1000)
A4: Yes, it can.
Verifier
Q1: Where do the Launcher and Verifier come from?
A1: (See Launcher Q1.)