1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
|
@node Spool
@cindex spool directory
@unnumbered Spool directory
Spool directory holds @ref{Encrypted, encrypted packets} received from
remote nodes and queued for sending to them. It has the following
example structure with just single outbound (@code{tx}) packet
@code{LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ} to the node
@code{2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ}:
@example
spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/toss.lock
spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/rx.lock
spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/rx/
spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/tx.lock
spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/tx/LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ
spool/tmp
@end example
@table @file
@cindex tmp directory
@item tmp
directory contains various temporary files that under normal
circumstances are renamed to necessary files inside other directories.
All directories in @file{spool} @strong{have to} be on the same
filesystem for working renaming.
@item 2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ
is an example Base32-encoded neighbour identifier.
@cindex rx directory
@cindex tx directory
@item rx, tx
directories are for incoming and outgoing encrypted packets. @file{rx}
contains currently unfinished, non-checked, unprocessed, etc packets.
@cindex lock files
@item toss.lock, rx.lock, tx.lock
Lock files. Only single process can work with @file{rx}/@file{tx}
directories at once.
@item LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ
is an example @ref{Encrypted, encrypted packet}. Its filename is Base32
encoded @ref{MTH} hash of the whole contents. It can be integrity checked
anytime.
@cindex part files
@item LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ.part
is an example @strong{partly} received file. It can appear only when
online transfer is used. Its filename is sent by remote side and until
file is fully downloaded -- it plays no role.
@cindex nock files
@item LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ.nock
non-checksummed (NoCK) @strong{fully} received file. Its checksum is
verified against its filename either by @command{@ref{nncp-check}}, or
by working online daemons. If it is correct, then its extension is trimmed.
@cindex seen files
@item seen/LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ
@command{@ref{nncp-toss}} utility can be invoked with @option{-seen}
option, leading to creation of @file{seen/} files, telling that the file
with specified hash has already been processed before. It could be
useful when there are use-cases where multiple ways of packets transfer
available and there is possibility of duplicates reception. You have to
manually remove them, when you do not need them (probably because they
are expired).
@cindex hdr files
@anchor{HdrFile}
@item hdr/LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ
If no @ref{CfgNoHdr, nohdr} option is enabled in configuration file,
then @file{hdr/} files are automatically created for every ordinary
(fully received and checksummed) packet. It literally contains just the
header of the corresponding packet. It will be automatically created
even during simple @command{@ref{nncp-stat}} call. On filesystems with
big blocksize (ZFS for example) it can greatly help listing the packets
in directories, because it prevents unnecessary read-amplification. On
other filesystems probably it won't help at all, or even harm
performance.
There is a hack: you can create more dense @file{hdr/} allocation by
removing all @file{hdr/} files and then running @command{@ref{nncp-stat}},
that will recreate them. In many cases many @file{hdr/} files will be
allocated more or less linearly on the disk, decreasing listing time
even more.
@cindex ack files
@anchor{ACKFile}
@item tx/ack/LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ
If tossing was performed with @option{-gen-ack} option, then for each
generated @ref{ACK} packet there will be corresponding empty @file{ack/}
file. ACK outbound packets needs to be deleted after the transmission,
but since they are stored encrypted in the spool, there needs to be some
kind of knowledge what packets are ACK ones. Both ACK and corresponding
@file{ack/} files are removed by @command{@ref{nncp-rm} -ack} command.
@end table
|
