Hi Chris, [EMAIL PROTECTED] wrote:
One config file is good. So it will be configured on the CA and the dataexchange will pass the XML config file to the nodes (yes ?).
Yes.
2. database I think about the following: - key (a simple serial from a generator) - objecttype - objectstatus - objectkey - received (textkey) - upload (textkey) - downloaded (textkey) - enroll (textkey with length equals number of possible nodes divided by four)I am confused by the last field, I don't understand the textkey length stuff.
Example: 8 nodes
=> 8 bits to store the commits
=> represent the bits in hex digits
=> needs to hex digits
=> needs two bytes in a text string to store it
=> 2bytes/8bits
=> factor 1/4
The idea is that the commits are bitstrings which contain the same information like our todays log files of the dataexchange. Bit 18 contains a true or false for module id 18.So this bit string says which node has received the object, yes ?
Yes, it is exactly the same like today - only in a bitmap.
Cool. So would this table (or set of tables) be updated each time the dataexchange file is received.
... and enrolled. Yes, it is like a log (but not only an informal one).
I like the idea of a clean design, even if it means a little sacrifice in performance.
I prefer the clean design too. Debugging and maintenance of such design is usually easier.
I still don't quite understand the full picture... is there any chance of an example in words, i.e. CA enrols, query on CA database, all records extracted to an SQL file (?), file tarred (and compressed) with config file, sent to nodes...
Ok, it is really complex. so I try a rudimentary example of the internal logic.
1. daemon startup 1.1. load dataexchange.xml 1.2. build hierarchy tree 1.3. calculate which are my children 1.4. calculate which datatypes I must export to them 1.5. load the datatype which I send/get from my parent 2. export data to child 2.1. export config (e.g. dataexchange.xml) 2.2. check which objects of which datatype must be exported to the child 2.3. export these objects 2.4. write logs of this 2.5. export my import logs from this childI hope this gives an overview about the logic inside. I don't like more details because the details are to implementation specific for a design discussion. Point 2.2 is the most performance critical one.
A real design question, I think about a small modification of the second approach:
- first table (unchanged) with object infos - second table with key, module/server/node id and the stateThis approach makes reports and database maintenance more easier. Every relevant combination of object, status and module id has an entry. We only need the following:
1. a maintenance command which creates the necessary entries in the second table
2. an export command (which is our performance problem today) which only scan the table for the rows with status EXPORT. We do not scan the object tables directly.
The maintenance command is perhaps a little bit slow but can be issued really easily via a cronjob. I think it is generally a good idea to split database maintenance and export. If the user don't like it then he can execute it at once.
Michael P.S. I try to make a picture from the exchange of the commits. -- _______________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 [EMAIL PROTECTED] D-10099 Berlin _______________________________________________________________
smime.p7s
Description: S/MIME Cryptographic Signature
