blob: 0bcdbc829cdf3c58a7366cdbf111ce6eca666414 (
plain)
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
|
Scire Server Backend Design Details:
Single points of failure:
Database. workaround: db replication
one server daemon. workaround: run multiple server daemons connecting to the
same databse. The configuration scripts will be made to handle failing over
from a primary server daemon to an alternate.
On startup, the server will need to check and deal with the possibility that
it needs to recover from failure. This could include making a query to check
for jobs that are to be sent to client programs running in daemon mode.
This could also include checking for jobs that were sent but did not return a
response saying they were received.
After recovery procedures, the server program will start the XMLRPC server
(over a secure socket of course), register itself to the network, and await
connections.
If a client program is configured to run in daemon mode (which is not
advised), and a job is "pushed" to a client, this is done by sending a small
RPC to the client program demanding that it ask for work immediately rather
than on its normal schedule.
Clients will be able to register/connect to the XMLRPC server for many
purposes. Most will be to either ask for work or to report the status of a
job that was sent to a client.
Asking for work:
When a client program registers and makes a connection to the server, it will
fork a thread on the server program for that client. Max-threads will be
define-able if necessary. Inside the thread, a query will be made to the
database to find jobs waiting to be sent to that client. All pending jobs
will be then checked against the ACL for the correct permissions. If the
check fails, update the status in the database and log accordingly. If the
check passes, reply to the client RPC by creating an XML job file on the fly
from the contents of the database row. Await a reply from the client that it
received this job and is waiting for more jobs. Send more jobs accordingly.
If the client does not reply saying it receives a message, ???
Updating the status of a job:
Don't know about threads here. May not be necessary. The client will connect
and state the job id# and the status of that job in an XML file. The server
program will parse and process the contents and update the database. The
server program will then reply to the client acknowledging the receipt of the
status message.
|
GitWeb
