dictd(8)

dictd - a dictionary database server

dictd is a server for the Dictionary Server Protocol (DICT), a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases.

For many years, the Internet community has relied on the "webster" protocol for access to natural language definitions. The webster protocol supports access to a single dictionary and (optionally) to a single thesaurus. In recent years, the number of publicly available webster servers on the Internet has dramatically decreased.

When a client connects, the global access specification is scanned, in order, until a specification matches. If no access specification exists, all access is allowed (e.g., the action is the same as if "allow *" was the only item in the specification). For each item, both the hostname and IP are checked. For example, consider the following access specification: With this specification, all clients in the 10.42 network will be allowed access to unrestricted databases; all clients from *.edu sites will be allowed to authenticate, but will be denied access to all databases, even those which are otherwise unrestricted; and all other clients will have their connection terminated immediately. The 10.42 network clients can send an AUTH command and gain access to restricted databases. The *.edu clients must send an AUTH command to gain access to any databases, restricted or unrestricted. If the client authenticated as u1, then the client will have access to this database, even if the client comes from a *.com site. In contrast, if the client authenticated as u2, the client will only have access if it does not come from a *.com site. In this case, the "user u2" is redundant, since that client would also match "allow *".

The DICT standard specifies a few search algorithms that must be implemented, and permits others to be supported on a server-dependent basis. The following search strategies are supported by this server. Note that all strategies are case insensitive. Most ignore non-alphanumeric, non-whitespace characters.

exact	An exact match. This algorithm uses a binary search and is one of the fastest search algorithms available.
lev	The Levenshtein algorithm (string edit distance of one). This algorithm searches for all words which are within an edit distance of one from the target word. An "edit" means an insertion, deletion, or transposition. This is a rapid algorithm for correcting spelling errors, since many spelling errors are within a Levenshtein distance of one from the original word.
prefix	Prefix match. This algorithm also uses a binary search and is very fast.
nprefix
	Like prefix but returns the specified range of matches. For example, when prefix strategy returns 1000 matches, you can get only 100 ones skipping the first 800 matches. This is made by specified these limits in a query like this: 800#100#app, where 800 is skip count, 100 is a number of matches you want to get and "app" is your query. This strategy allows to implement DICT client with fast autocompletion (although it is not trivial) just like many standalone dictionary programs do. NOTE: If you access the dictionary "*" (or virtual one) with nprefix strategy, the same range is set for each database in it, but globally for all matches found in all databases. NOTE: In case you access non-english dictionary the returned matches may be (and mostly will be) NOT ordered in alphabetic order.
re	POSIX 1003.2 (modern) regular expression search. Modern regular expressions are the ones used by egrep(1). These regular expressions allow predefined character classes (e.g., [[:alnum:]], [[:alpha:]], [[:digit:]], and [[:xdigit:]] are useful for this application); uses * to match a sequence 0 or more matches of the previous atom; uses + to match a sequence of 1 or more matches of the previous atom; uses ? to match a sequence of 0 or 1 matches of the previous atom; used ^ to match the beginning of a word, uses $ to match the end of a word, and allows nested subexpression and alternation with () and |. For example, "(foo|bar)" matches all words that contain either "foo" or "bar". To match these special characters, they must be quoted with two backslashes (due to the quoting characteristics of the server). Warning: Regular expression matches can take 10 to 300 times longer than substring matches. On a busy server, with many databases, this can required more than 5 minutes of waiting time, depending on the complexity of the regular expression.
regexp	Old (basic) regular expressions. These regular expressions don’t support |, +, or ?. Groups use escaped parentheses. While modern regular expressions are generally easier to use, basic regular expressions have a back reference feature. This can be used to match a second occurrence of something that was already matched. For example, the following expression finds all words that begin and end with the same three letters: ^\\(...\\).*\\1$ Note the use of the double backslashes to escape the special characters. This is required by the DICT protocol string specification (a single backslash quotes the next character -- we use two to get a single backslash through to the regular expression engine). Warning: Note that the use of backtracking is even slower than the use of general regular expressions.
soundex
	The Soundex algorithm, a classic algorithm for finding words that sound similar to each other. The algorithm encodes each word using the first letter of the word and up to three digits. Since the first letter is known, this search is relatively fast, and it sometimes good for correcting spelling errors when the Levenshtein algorithm doesn’t help.
substring
	Match a substring anywhere in the headword. This search strategy uses a modified Boyer-Moore-Horspool algorithm. Since it must search the whole index file, it is not as fast as the exact and prefix matches.
suffix	Suffix match. This search strategy also uses a modified Boyer-Moore-Horspool algorithm, and is as fast as the substring search. If the optional index_suffix string file is listed in the configuration file this search is much faster.
word	Match any single word, even if part of a multi-word entry. If the optional index_word string file is listed in the configuration file this search strategy works much faster.
first	Match the first word that begins a multi-word entry.
last	Match the last word that ends a multi-word entry. If the optional index_suffix string file is listed in the configuration file this search strategy works much faster.

Databases for dictd are distributed separately. A database consists of two files. One is a flat text file, the other is the index.

The main source files for the dictd server and the dictzip compression program were written by Rik Faith (faith) and are distributed under the terms of the GNU General Public License. If you need to distribute under other terms, write to the author.

The regular expression searches do not ignore non-whitespace, non-alphanumeric characters as do the other searches. In practice, this isn’t much of a problem.

Conformance of regular expressions (used by ’re’ and ’regexp’ search strategies) to ERE and BRE depends on library you build dictd with. Whether ’re’ and ’regex’ strategies support utf8 depends on library you build dictd with.

examples/dictd*.conf, dictfmt(1), dict(1), dictzip(1), gunzip(1), zcat(1), webster(1), RFC 2229

dictd(8), dictdconfig(8), dict(1), dict_lookup(1), dictzip(1), dictfmt(1), dictfmt_index2suffix(1), dictfmt_index2word(1), dictunformat(1), mate-dictionary(1)