1 This will be a module to synchronise two Citadel servers.
3 We should add comments here for features that are needed
6 The initial plan is that this module will provide services to allow
7 a new Citadel server to collect all data from an existing Citadel server
8 resulting in the new server being a complete duplicate of the original.
10 All data must be transfered over the wire.
11 The data synchronised should include the log in/out messages and anyfiles
12 in a room not just the content of the message base.
14 I think we should structure this as a series of commands that can be issued
15 in any order with the exception of one command that forces the exporting
16 server to go "single user" to ensure the system doesn't change during the sync.
18 These are the commands I can think of at the moment.
21 This will prevent new logins from happening and also prevent inbound messages
22 from SMTP, IMAP RSS and IGNET etc.
23 This command should allow real user to complete what they are doing and should
24 probably give them a message to say the system wants to go single user.
25 This command should take two arguments. The first is the time to wait for the
26 system to go single user. The second argument is the time to expire single user
27 mode if the requesting server disappears.
29 ESNG End single user mode.
31 SYNC Main command for all synchronisation options.
32 This is to be followed by 2 or more arguments.
33 Argument 1 is the type of Citadel data to be worked with eg. rooms, files
35 Argument 2 is the action to carry out on the specified data.
38 So a sequence might go something like this:
40 Unconfigured server. Old server
41 SNGL 120|500 Goes single user within 120
42 seconds. Reverts to normal
43 operation if no activity
46 SYNC users|info Send back info on the system
47 users. A CRC and a few other
48 items so that the requesting
49 server can determine if its
50 user data is out of sync.
52 SYNC users|getall Send back all users info.
54 ESNG Revert back to multi user mode.
57 Obviously there is lots to be worked out here. It may be a good idea to
58 timestamp every thing to determine the need for updates.
60 If we do this right this module could replace IGNET and ARTV and could be used
61 clients to sync mailboxes and calendars etc.
63 We should care a bit about performance here.
64 -> not use the sendcommand/ctdl_ipc here.
65 To gain performance, (profiler says...) we musn't read byte by byte aymore, but read blocks.
66 thus the out/input format should be a bit similar to the http chunked mode, sending blobs of
68 Probably up 64K windows are apropriate here. it could look like that:
71 AnotherMessageHeader=blub
75 < 2344 bytes; probably the overlaps of the message. >