Follow the submission instructions.
Remember to comment your code!
Stand-alone Spelling Checker Program (90 100 pts)
Spelling checkers are used frequently in text editors to show spelling mistakes in documents and possibly provide suggestions. Although conceptually simple, the procedure of finding close matches for a string from a set of strings in a dictionary can be extended to other operations such as search suggestions, giving users a list of commands with a similar spelling if a command is not found by the shell, etc.
In this assignment, you will implement a stand-alone spelling checker program that reads its input from standard input, and outputs results.
By default, the program should use the standard dictionary provided
by the system as the default dictionary. For example, /usr/share/dict/words in Linux. Your program should allow the use of -d or –dictionary command line switches to allow the user override the default dictionary requirement.
The program should expect one word per line of input, and should skip blank lines. If the newly read word is found from the dictionary, the word itself should be returned. If the word is not found, your spelling checker should print out suggestions. The suggestion words should not have an edit distance of larger than 2 from the input word. If no word that has an edit distance of 2 or less is found, the program should print out a blank line. If there is one or more words that have a distance of 2 or less, the spelling checker should print out those words as suggestions, sorted according to the edit distance (ascending). No more than 12 words should be printed as suggestions by default.
The logic is as follows:
If there is an exact match (edit distance 0), only print that string in a line.
If there is no match, print a blank line.
If there are 12 or fewer matches (with edit distances 1 or 2) after searching, print all of them. Strings with edit distance 1 should be printed before strings with edit distance 2. No specific requirement for sorting strings with the same edit distance.
If there are more than 12 matches:
If there are at least 12 matches with edit distance 1, print 12 matches from among them. Order does not matter. Therefore, you can stop searching for more matches once 12 matches with edit distance 1 are found.
If there are fewer than 12 matches with edit distance 1, print them first (if any), and print strings with edit distance 2 until a total of 12 matches are printed. As above, order does not matter among strings with the same edit distance.
Your spelling checker should print out the following line to mark the end of its output (even if it is blank) after processing each input word:
After this output, the spelling checker should wait for more user input, until user enters an EOF character (by pressing Ctrl-D, for example), or enters the following line:
The spelling checker should exit after such input.
A good spelling checker should consider the possibility of lower and upper cases in user input. However, for simplicity, the spelling checker is only expected to handle strings in case-sensitive manner. You may want to improve your spelling checker to handle strings in a case-insensitive way, but this is not required.
Your program should have the following command line options:
-d, –dictionary # override default dictionary with another file
-n, –count # override the default maximum number of suggestions
-v, –version # print version information
-h, –help # show help
An example run of the program may look
$ ./speller rever # user input
River # program output
speling # more user input
spelling # program output
wrooongg # more user input
# program output (blank line)
$ ./speller -d ./my_dictionary
$ ./speller -v
My spelling checker, version 0.1
$ ./speller -n 2
rever # user input
river # program output (only two suggestions)
You are encouraged to use hash tables for your implementation. Please make your program as modular as possible–you will modify this program later as a spelling checker daemon.
Since the attacker programs is expected to test input from both the command line and stdin, you may write two separate attacker programs for these two input channels. If you do this, please briefly document your attacker programs in the README file. Both can certainly be handled by single attacker program.
You may want to consider using GNU getopt library for processing command line options.
Spelling Checker Daemon (30 pts bonus)
Extra Credit (10 pts each)
Although the user can invoke the spelling checker from the command line, there are some disadvantages:
The dictionary file has to be read and words have to hashed every time a new session is started.
It is cumbersome for other programs at the host, or even on the Internet, to interface with your spelling checker to use its lookup and suggest services.
In this section, you modify your spelling checker program so that it can run as a “daemon” (or a service) on your system. When started, your spelling checker should check command line options, any error condition (not being able to load the dictionary, etc.), and then, if everything is fine, should become a “daemon” process, ready to accept request from a network socket. Like other daemon programs, closing the terminal used to start the spelling checker daemon should not end up closing the program.
Your spelling checker daemon should check for all error conditions before it becomes a daemon. If any error occurs it should stop gracefully with some meaningful error message.
Your program should have the command line options in the previous section and the following option:
-p, –port # TCP port to receive requests.
# Default is 1234.
Your spelling checker program should use a TCP socket for incoming connections. The default port number should be 1234, but should be adjustable with a command line option.
To be easily found, the spelling checker daemon should store its PID to a well-known location, such as:
Since a client can potentially block other clients by opening up a connection and sitting idle afterwards, your spelling checker daemon should be concurrent. It is recommended that you use the “fork” system call that we have already learned to handle multiple clients concurrently.
Other options, operations, and processing logic should be the same with the stand-alone spelling checker specified in the previous section.
Extra Credit (10 pts each)
Add a feature to your spelling checker daemon so that it opens a log file, locks it, and use it for logging the time, the IP address, and the requested word for each incoming request. File locking can be used to give the user a suitable error message when the user tries to start your spell checker when another instance is running.
Add a feature to your spelling checker daemon so that it can receive and process the SIGHUP signal. Upon receiving SIGHUP, the spelling checker should reload the dictionary file. This is useful when you want to use a new dictionary, but do not want to shutdown and start your daemon all over again. You should also log this event.
A sample execution session may look something
$ ./spelld # start spelling checker daemon
(should go to background)
$ telnet localhost 1234
Connected to localhost.
Escape character is ‘^]’
rever # user input
revet # program output
Wroonggg # more user input
# blank line means word not found,
and no suggestions
^] # pressing “ctrl+]” ends telnet session
telnet$ ^d # telnet prompt. Press “ctrl-d” to exit
$ ./spelld # start spelling checker daemon
$ ./spelld # try to start another one
spelld: It seems that another instance of this program is running already with pid 4567. Exiting.
$ kill -HUP 4567 # tell the daemon to reload the dictionary
Your attacker program(s) should exercise command line options and input/output to/from the spelling checker daemon’s network socket.
Assignments should be submitted to the appropriate assignment Dropbox in D2L in a single zip file that conforms to the specifications described below.
Submissions MUST compile without warnings, or they cannot be graded.
All the files related to the assignment should be placed in a folder named assignmentX.
Create a ONE zip file for the folder with the following naming format:
where ‘X’ is the number of the assignment (1,2,3, …) and ‘addr’ is replaced with your Metro State email ID. For example, my submission for assignment 1 would be:
‘README’ file produced with an ASCII text editor (a text file produced using TextPad, Notepad++, nano, vim, etc, NOT Doc nor PDF) that:
lists your name and anyone you worked with
explains whether or not all problems were solved and to what degree
lists what sources, if any, you used to produce the code that solves the assignment problems
‘Makefile’ that controls the build process. An example of such a file is on the class website. You can reuse this file with minor modifications.
Any reasonable number of C source files (.c) and header files (.h) that contain the source code for your solutions. The files should be appropriately named so that the grader can distinguish which source files correspond to which assignment problem. The assignments rarely require more than one .c file per problem.
A set of test data files that show that your program works as intended.
An attacker program called “attacker.c” that actively probes your program via its input channels (stdin, file I/O, cmd line arguments, environment variables, network sockets, etc.). The attacker program should behave like a normal driver program that exercise program functionalities, except that it should put more focus on revealing possible security holes, or any other areas that affect program reliability. This file should be built by your Makefile at the same time as your programming solution is built. Please take a look at the attached sample attacker programs for a reference.
Do not include any binaries, object files, messages, backup files, web pages, core dumps, etc.
It is to your advantage to accomplish small tasks completely in the assignment (and explain this in your README) if you are unable to finish the whole problem. It is better to be graded on a single working sub-part than a broken whole.
The process of compiling is often repetitive. The process of compiling (using gcc to compile your C code to machine code) can be automated. This automation is accomplished by using another tool called ‘make.’ A Makefile is a specially named file that tells ‘make’ how to compile C source code. Usually, once you’ve written a Makefile and stored it in the same directory as your source code, all you have to do to build your source code is type ‘make’ at the command prompt.
Your Makefile should always contain a ‘clean’ target; that is, typing the following at the command line:
$ make clean
will delete object files, executables, and backup files, just leaving your source code, the README, and the Makefile.
Secondly, your Makefile should always tell gcc to compile with warnings on by passing the -Wall switch to gcc. Your submission should compile without warnings. An additional useful flag is -g, which compiles your program with debugging information.
$ cd cybr621/code
assignment1/ assignment2/ assignment3/ …
$ cd assignment1/
$ make clean
assignment1.c Makefile assignment1.h README
$ cd ..
$ zip assignment1-ibrahim.el-shekeil.zip assignment1/
assignment1/ assignment1-ibrahim.el-shekeil.zip assignment2/ assignment3/ …
Now you can now upload the zip file.
Assignment status: Already Solved By Our Experts
(USA, AUS, UK & CA Ph. D. Writers)
QUALITY: 100% ORIGINAL PAPER – NO PLAGIARISM – CUSTOM PAPER