Commit 1e048fcf authored by Mike Hibler's avatar Mike Hibler
Browse files

Checkpoint on going update.

parent e0515283
#
# EMULAB-COPYRIGHT
# Copyright (c) 2000-2003 University of Utah and the Flux Group.
# Copyright (c) 2000-2010 University of Utah and the Flux Group.
# All rights reserved.
#
......@@ -9,11 +9,22 @@
#include <event.h>
event_handle_t event_register(char *name, int threaded);
event_handle_t event_register_withkeyfile(char *name, int threaded, char *keyfile);
event_handle_t event_register_withkeydata(char *name, int threaded, unsigned char *keydata, int len);
event_handle_t event_register_withkeyfile_withretry(char *name, int threaded, char *keyfile, int retrycount);
event_handle_t event_register_withkeydata_withretry(char *name, int threaded, unsigned char *keydata, int len, int retrycount);
Register with the testbed event system. NAME specifies the name of
the event server. Returns a pointer to a handle that may be passed
to other event system routines if the operation is successful, NULL
otherwise.
Register with the testbed event system with an optional HMAC key.
In all forms, NAME specifies the name of the event server and THREADED is
an indication as to whether the calling application is multi-threaded.
Returns a pointer to a handle that may be passed to other event system
routines if the operation is successful, NULL otherwise.
The syntax of the NAME parameter is inherited from elvin, and is a subset
of their URI syntax. It is of the form elvin://<server>:<port> where
<server> is the IP or DNS name of the server, and PORT is the TCP port
number to use.
The THREADED parameter should be set to 1 if the registering
client is multi-threaded. If THREADED is 1, the event
......@@ -24,16 +35,16 @@
event loop, and the client must call event_main after connecting in
order to receive notifications.
Elvin note: NAME is a URL of the form "elvin:/[protocol
stack]/[endpoint]", where a protocol stack names a transport
module, a security module, and a marshaling module as a comma
separated list (e.g., "http,none,xml"), and the endpoint format
is dependent on the transport module used. If no protocol
stack is given, the default stack (tcp, none, xdr) is used. For the
testbed's purposes, "elvin://HOSTNAME" should suffice. If NAME
is NULL, then Elvin's server discovery protocol will be used to find
the Elvin server.
In the _withretry forms, RETRYCOUNT is the number of attempt to try
making a connection to the server before failing. Retries happen
at a transport-specific interval, in the case of pubsub (the current
and only supported transport) it is 5 seconds.
In the _withkey* forms, the given KEYDATA and LEN or the contents of
KEYFILE are used as a key for the keyed-hash MAC computation to
authenticate all events sent or received via the returned handle.
The HMAC is a SHA1 hash computed using the OpenSSL HMAC_* routines.
Event HMACs appear as opaque attributes in events.
* event_unregister: Unregister with the testbed event system
......@@ -52,9 +63,20 @@
int event_main(event_handle_t handle);
Enter the main loop of the event system, waiting to receive event
notifications. Returns non-zero if the operation is successful, 0
otherwise.
notifications. Remains in the main loop until an error occurs or
event_stop_main is called. Returns non-zero if the operation is
successful, 0 otherwise. Should only be called by single-threaded
programs.
* event_stop_main: Force event_main to return
#include <event.h>
event_stop_main(event_handle_t handle)
Can be called from an event handler or signal handler to force the
main loop to return, either to check for a completion condition or
to handle other, non event related processing.
* event_notify: Send an event notification
......@@ -67,6 +89,8 @@
allocated by event_notification_alloc, and may optionally
have attributes added to it by event_notification_put_*.
Returns non-zero if the operation is successful, 0 otherwise.
If HANDLE has an associated hash key, an HMAC is computed and
added as an attribute before sending.
Note that NOTIFICATION is not deallocated by event_notify. The
caller is responsible for deallocating the notification when it
......@@ -81,15 +105,23 @@
event_notification_t notification,
struct timeval *time);
Schedule the event notification NOTIFICATION to be sent at time
TIME. NOTIFICATION is allocated by event_notification_alloc,
Send the indicated notification as a "scheduled" event.
NOTIFICATION is allocated by event_notification_alloc,
and may optionally have attributes added to it by
event_notification_put_*. Returns non-zero if the operation
is successful, 0 otherwise.
This function essentially operates as a deferred event_notify.
event_notify sends notifications immediately,
whereas event_schedule sends notifications at some later time.
event_notify sends notifications immediately to recipients,
whereas event_schedule causes notifications to be sent at
some later time.
IMPORTANT NOTE: scheduled events are NOT held in the calling process
for later delivery. Instead, event_schedule adds a SCHEDULER=1 attribute
to the notification along with attributes for the delivery time, and
then uses event_notify to immediately send the event. There must be
an event agent subscribed to SCHEDULER events that implements the
queuing and later sending of the unadorned notification.
Note that NOTIFICATION is not deallocated by event_schedule.
The caller is responsible for deallocating the notification
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment