| 1 | = Trickle messages = |
| 2 | |
| 3 | '''Trickle messages''' let applications communicate with the server during the execution of a workunit. They are intended for applications that have long workunits (multiple days). |
| 4 | |
| 5 | Trickle messages may from client to server or vice versa. Messages are XML documents. |
| 6 | |
| 7 | == Trickle-up messages == |
| 8 | '''Trickle-up''' messages go from application to server. They are handled by '''trickle handler daemons''' running on the server. Each message is tagged with a 'variety' (a character string). Each daemon handles messages of a particular variety. (This is used, typically, to distinguish different applications.) Example uses: |
| 9 | * The application sends a trickle-up message containing its current CPU usage, so that users can be granted incremental credit (rather than waiting until the end of the work unit). |
| 10 | * The application sends a trickle-up message containing a summary of the computational state, so that server logic can decide if the computation should be aborted. |
| 11 | |
| 12 | To create a trickle handler daemon, modify the program sched/trickle_handler.C, replacing the function handle_trickle() with your own function. Add an entry in your [ProjectConfigFile config.xml] to run this program as a daemon. |
| 13 | |
| 14 | == Trickle-down messages == |
| 15 | |
| 16 | '''Trickle-down''' messages go from server to application. Each one is addressed to a particular host, and must include an element <result_name> identifying the result to which the message is addressed. If that result is still running on the host, it is delivered to it. Example uses: |
| 17 | * The server sends a message telling the application to abort. |
| 18 | * The server sends a message containing the user's current total credit. |
| 19 | |
| 20 | Trickle messages are asynchronous, ordered, and reliable. Trickle messages are conveyed in scheduler RPC messages, so they may not be delivered immediately after being generated. |