diff dblist.0 @ 0:c7f6b056b673

First import of vendor version
author Peter Gervai <grin@grin.hu>
date Tue, 10 Mar 2009 13:49:58 +0100
parents
children
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/dblist.0	Tue Mar 10 13:49:58 2009 +0100
@@ -0,0 +1,152 @@
+dblist(8)             Distributed Checksum Clearinghouse             dblist(8)
+
+NNAAMMEE
+     ddbblliisstt -- Database List Distributed Checksum Clearinghouse
+
+SSYYNNOOPPSSIISS
+     ddbblliisstt [--vvVVHHDD] [--GG _o_n | _o_f_f] [--hh _h_o_m_e_d_i_r]
+            [--ss [_s_e_r_v_e_r_-_I_D][_,_s_e_r_v_e_r_-_a_d_d_r][_,_s_e_r_v_e_r_-_p_o_r_t]]
+            [--CC _'_t_y_p_e _h_1 _h_2 _h_3 _h_4_'] [--II _s_e_r_v_e_r_-_I_D] [--AA _d_b_a_d_d_r] [--LL _p_a_t_h_l_e_n]
+            [--PP _p_a_g_e_s] [--TT _t_i_m_e_s_t_a_m_p] [_f_i_l_e_1 _f_i_l_e_2 _._._.]
+
+DDEESSCCRRIIPPTTIIOONN
+     DDbblliisstt lists the contents of a DCC database as it does some consistency
+     checking.
+
+     --vv   lists more of the database.  Additional information is produced with
+          additional --vv arguments.
+
+     --VV   displays the version of the DCC database lister.
+
+     --HH   turns off the listing of the hash table as well as the analysis of
+          the hash table.  Determining the worst case and average lengths of
+          chains in the hash table can take a long time for a large database
+          on a small computer.
+
+     --DD   turns off the listing of the data or checksum records.
+
+     --GG _o_n
+          lists a greylist database.
+
+     --hh _h_o_m_e_d_i_r
+          overrides the default DCC home directory, _/_v_a_r_/_d_c_c.
+
+     --ss [_s_e_r_v_e_r_-_I_D][_,_s_e_r_v_e_r_-_a_d_d_r][_,_s_e_r_v_e_r_-_p_o_r_t]
+          somewhat quiets the DCC server process, dccd(8), to get somewhat
+          more consistent results.  _s_e_r_v_e_r_-_I_D must be in the _i_d_s file.
+          _s_e_r_v_e_r_-_a_d_d_r and _s_e_r_v_e_r_-_p_o_r_t are the IP address and UDP port at which
+          the server process listens.
+
+     --CC _'_t_y_p_e _h_1 _h_2 _h_3 _h_4_'
+          limits the listing to records containing that checksum or one of the
+          other checksums specified with --CC.  If the four hexadecimal values
+          _h_1 _h_2 _h_3 _h_4 are absent, records with the matching _t_y_p_e will be
+          listed.  If _t_y_p_e is absent, any checksum with the four hexadecimal
+          values will be listed.  As many as 16 checksums can be specified.
+
+     --II _s_e_r_v_e_r_-_I_D
+          limits the listing to records with that server-ID or one of the
+          other server-IDs specified with --II.  As many as 16 server-IDs can be
+          specified.
+
+     --AA _d_b_a_d_d_r
+          excludes database records before _d_b_a_d_d_r.
+
+     --LL _p_a_t_h_l_e_n
+          excludes records with path lengths shorter than _p_a_t_h_l_e_n.
+
+     --PP _p_a_g_e_s
+          ignores all but the last _p_a_g_e_s of the database.
+
+     --TT _t_i_m_e_t_a_m_p
+          excludes records with other timestamps.  A timestamp with a missing
+          microsecond value matches any record with that second.  As many as
+          16 timestamps can be specified.
+
+     _f_i_l_e_1 _f_i_l_e_2 _._._.
+          are names of databases to be listed.  The default is _d_c_c___d_b and its
+          companion, _d_c_c___d_b_._h_a_s_h in the DCC home directory.
+
+     By default, the sizes of the main file and the hash table as well as how
+     much they contain and values related to the performance of the hash are
+     displayed.
+
+     With a single --vv, most of the mail database file and the contents of mem-
+     ory mapped server flooding positions in the _f_l_o_d_._m_a_p file  are listed.
+     The listing starts with the serial number of the database file which is
+     when old entries were last removed from it by dbclean(8) That is followed
+     by similar lines showing the oldest timestamp of checksums not expired by
+     dbclean and of mail that is not "spam."
+
+     The flooding positions from the _f_l_o_d_._m_a_p file are record offsets or
+     addresses in the main database file.
+
+     A typical record in the main database file looks like:
+
+     02/07/02 20:25:12.497032    5    auth 1601              2fe5b94
+          path: 103<-101<-1601
+       Body      6       e2d3f96a c65aea01 3fece361 edff9ecf  2f21364 772d2
+       Fuz1      many    6ff56fe8 ffc312d7 a5fe8f13 12a537ae  2f21364 200a9
+       Fuz2      many    fac882b8 03eea34f bd792c40 2fe6fd54  2f21364 72816
+
+     That example was received by a DCC server with server-ID _1_6_0_1 at about
+     8:25 UTC on the evening of February 7, 2000.  The report was about a mail
+     message set to _5 addressees.  The report was from a client that presented
+     a client-ID and matching password that the server recognized or authenti-
+     cated.  The report was then sent or `flooded' to the server with server-
+     ID _1_0_1 which in turn sent it to a server with server-ID _1_0_3.  That server
+     sent it to the local DCC server.  The record is at the address _0_x_2_f_e_5_b_9_4
+     in the database.  The record contains 3 checksums.  The simple checksum
+     of the body of the message was _e_2_d_3_f_9_6_a _c_6_5_a_e_a_0_1 _3_f_e_c_e_3_6_1 _e_d_f_f_9_e_c_f The
+     total number of recipients of messages with this body checksum known in
+     the database is _6, which implies this checksum had been previously
+     reported with a target count of 1.  The previous report in the database
+     of a message with this body checksum is at _0_x_2_f_2_1_3_6_4.  The hash table
+     entry for this body checksum is at _0_x_7_7_2_d_2.  This report included two
+     fuzzy checksums.  Both have been previously reported as having been sent
+     to _m_a_n_y targets.
+
+     An asterisk (*) before the name of the checksum would indicate that a
+     later record in the database makes this checksum redundant.  A report of
+     _m_a_n_y addressees makes all preceding reports redundant.
+
+     The string _t_r_i_m_m_e_d after the server-ID marks older reports that have had
+     uninteresting checksums removed.  The string _c_o_m_p_r_e_s_s_e_d after the server-
+     ID would indicate that this older report has been trimmed and compressed
+     with older reports.
+
+     With two --vv arguments, records added to the database by dbclean(8) from
+     the server whitelist are also displayed.
+
+     Three --vv arguments cause the hash table to be displayed.  Three typical
+     hash table entries look like:
+
+           19b8:   19ee   19b7
+           19b9:   19c0      0    90120 Fuz1
+           19ba:      0      0  1b72300 Fuz1
+
+     The entry in slot number _0_x_1_9_b_8 is unused or free.  Slot number _0_x_1_9_b_9 is
+     the start of a chain of collisions or entries with the same hash value of
+     0x19b9.  The next slot in this chain is at _0_x_1_9_c_0.  The corresponding
+     _F_u_z_1
+      checksum is at _0_x_9_0_1_2 in the database.  The third slot at _0_x_1_9_b_a is also
+     that of a _F_u_z_1 checksum, but it is not part of a hash chain and its data-
+     base record is at _0_x_1_b_7_2_3_0_0.
+
+FFIILLEESS
+     /var/dcc     is the DCC home directory containing data and control files.
+     dcc_db grey_dcc_db
+                  main file of checksums.
+     dcc_db.hash grey_dcc_db.hash
+                  database hash table.
+     flod.map grey_flod.map
+                  memory mapped flooding positions.
+
+SSEEEE AALLSSOO
+     cdcc(8), dcc(8), dbclean(8), dccd(8), dccifd(8), dccm(8), dccproc(8).
+
+HHIISSTTOORRYY
+     Implementation of ddbblliisstt was started at Rhyolite Software, in 2000.  This
+     document describes version 1.3.103.
+
+                               February 26, 2009