user name (translated to lower case for indexing purposes). The records in
this file look something like this:
+```
struct ctdluser { // User record
int version; // Citadel version. which created this record
uid_t uid; // Associate with a unix account?
int USuserpurge; // Purge time (in days) for user
char fullname[64]; // Name for Citadel messages & mail
};
+```
Most fields here should be fairly self-explanatory. The ones that might
deserve some attention are:
system, public or private or mailbox. It's indexed by room name (also in
lower case for easy indexing) and it contains records which look like this:
+```
struct ctdlroom {
char QRname[ROOMNAMELEN]; /* Name of room */
char QRpasswd[10]; /* Only valid if it's a private rm */
unsigned QRflags2; /* Additional flags */
int QRdefaultview; /* How to display the contents */
};
+```
Again, mostly self-explanatory. Here are the interesting ones:
Here's what the records look like:
+```
struct visit {
long v_roomnum;
long v_roomgen;
#define V_FORGET 1 /* User has zapped this room */
#define V_LOCKOUT 2 /* User is locked out of this room */
#define V_ACCESS 4 /* Access is granted to this room */
+```
This table is indexed by a concatenation of the first three fields. Whenever
we want to learn the relationship between a user and a room, we feed that
message may exist in more than one room, it's important to keep this reference
count up to date, and to delete the message from disk when the reference count
reaches zero.
+
+NoSQL pros might recognize the message store as a "document database". Each
+record is an arbitrary collection of keys and values, some of which may
+appear all the time, and some which might appear infrequently.
# Here's the format for the message itself:
| | | | | Optional, and only in Mail messages.
| % | eHeaderOnly | nhdr | oNlyHeader | we will just be sending headers. for the Wire protocol only.
| % | eFormatType | type | type | type of citadel message: (Wire protocol only)
- | | | | | FMT\_CITADEL 0 Citadel vari-format (proprietary)
- | | | | | FMT\_FIXED 1 Fixed format (proprietary)
- | | | | | FMT\_RFC822 4 Standard (headers are in M field)
+ | | | | | FMT_CITADEL 0 Citadel vari-format (proprietary)
+ | | | | | FMT_FIXED 1 Fixed format (proprietary)
+ | | | | | FMT_RFC822 4 Standard (headers are in M field)
| % | eMessagePart | part | emessagePart | eMessagePart is the id of this part in the mime hierachy
| % | eSubFolder | suff | eSubFolder | descend into a mime sub container
| % | ePevious | pref | ePevious | exit a mime sub container
Let `<FF>` be a `0xFF` byte, and `<0>` be a null `(0x00)` byte. Then a message
which prints as...
+```
Apr 12, 1988 23:16 From Test User In Network Test> @lifesys (Life Central)
Have a nice day!
+```
might be stored as...
+```
<FF><40><0>I12345<0>Pneighbor!lifesys!test_user<0>T576918988<0> (continued)
-----------|Mesg ID#|--Message Path---------------|--Date------
AThe Test User<0>ONetwork Test<0>Nlifesys<0>HLife Central<0>MHave a nice day!<0>
|-----Author-----|-Room name-----|-nodename-|Human Name-|--Message text-----
+```
Weird things can happen if fields are missing, especially if you use the
networker. But basically, the date, author, room, and nodename may be in any
Therefore when you save an updated version of an address book entry or
a calendar item, the old one is automatically deleted.
-NETWORKING (REPLICATION)
-------------------------
-Citadel nodes network by sharing one or more rooms. Any Citadel node
-can choose to share messages with any other Citadel node, through the sending
-of spool files. The sending system takes all messages it hasn't sent yet, and
-spools them to the recieving system, which posts them in the rooms.
-
-The *EUID* discussion above is extremely relevant, because *EUID* is carried over
-the network as well, and the replacement rules are followed over the network
-as well. Therefore, when a message containing an *EUID* is saved in a networked
-room, it replaces any existing message with the same *EUID* *on every node in
-the network*.
-
-Complexities arise primarily from the possibility of densely connected
-networks: one does not wish to accumulate multiple copies of a given
-message, which can easily happen. Nor does one want to see old messages
-percolating indefinitely through the system.
-
-This problem is handled by keeping track of the path a message has taken over
-the network, like the UseNet news system does. When a system sends out a
-message, it adds its own name to the bang-path in the *<P>* field of the
-message. If no path field is present, it generates one.
-
-With the path present, all the networker has to do to assure that it doesn't
-send another system a message it's already received is check the <P>ath field
-for that system's name somewhere in the bang path. If it's present, the system
-has already seen the message, so we don't send it.
-
-We also keep a small database, called the "use table," containing the ID's of
-all messages we've seen recently. If the same message arrives a second or
-subsequent time, we will find its ID in the use table, indicating that we
-already have a copy of that message. It will therefore be discarded.
-
-The above discussion should make the function of the fields reasonably clear:
-
- o Travelling messages need to carry original message-id, system of origin,
- date of origin, author, and path with them, to keep reproduction and
- cycling under control.
-
-(Uncoincidentally) the format used to transmit messages for networking
-purposes is precisely that used on disk, serialized. The current
-distribution includes serv_network.c, which is basically a database replicator;
-please see network.txt on its operation and functionality (if any).
-
PORTABILITY ISSUES
------------------
Citadel is 32/64 bit clean and architecture-independent. The software is
projects / citadel.git / blobdiff