[Openais] Adding a service

Steven Dake sdake at mvista.com
Tue Jul 27 13:36:44 PDT 2004

On Tue, 2004-07-27 at 09:28, Mark Haverkamp wrote:
> On Fri, 2004-07-23 at 15:08, Mark Haverkamp wrote:
> > On Fri, 2004-07-23 at 14:57, Steven Dake wrote:
> [ ... ]
> > > This code basically checks if the queue is empty, then reads from the
> > > queue if there is a request, otherwise it reads from the socket.
> > 
> > OK, I think that looks like what I want to do.  I'll go through the code
> > and make sure.
> > 
> The receive queue function seem to be working for me.
> The next thing I'd like to have is a handle data base in my server side
> code.  I see that there are some handle database functions in aispoll.c,
> but there are no externs for access.  Could we put some externs for
> these function in a header file somewhere, or better yet, is there any
> reason that the handle database functions on the server are different
> than the library ones?  Would it make sense to have just one set of
> handle database functions that any of the code could use?


I'd like to keep the library seperate from the executive, even if the
code is duplicated.  While this makes it a little more difficult to
maintain, it makes analyzing code coverage easier for a particular
executible and allows us to say with confidence that we have achieved
XX.X% code coverage.  That is why the aispoll duplicates the handle code
(although a much older version).  

We can add the handle code, but you might consider how to manage state
tracking between api invocations without using handles.  I had always
hoped all of the services could be implemented without the need for
global handles in the executive (although per connection handles are
probably ok).  The problem with handles used to track info between api
invocations, is that someone else can guess the handle in a different
context and corrupt your context.  It could even be some totally
different application that has some bug (and is not an intentional
attack)  This would be bad news for security and reliability.  I have
had a goal that any api can only at worst break its own process's
operation if the application is buggy, but not for other api users.

Each connection can maintain seperate (and secure) state.  There is no
way (except for memory bugs in the executive) for one connection to
corrupt another connection's state.  This is done through the
conn_info->ais_ci passed to every library handler in the service
structure.  The ais_ci structure is a union of structures for each of
the services.  As an example, look at the checkpoint connection info
structure which is libckpt_ci:

struct libckpt_ci {
    struct saCkptCheckpoint *checkpoint;
    SaCkptCheckpointOpenFlagsT checkpointOpenFlags;
    struct saCkptSectionIterator sectionIterator;

This structure is then used to track the checkpoint open flags for a
checkpoint, the name of the checkpoint, and the current value of the
section iterator.  Every connection to the executive sets these values
as necessary and each connection has a seperate storage area for the
conn_info->ais_ci information.

As another example look at:
struct libamf_ci {
    struct libamf_ci_trackentry *tracks;
    int trackEntries;
    int trackActive;

This is used for tracking in the AMF API.  the *tracks is an array of
tracks.  Each connection can have multiple tracks so this data structure
is repeated for each library connection.

Let me know if this approach wont work for you, and I can do some
cleanup on the handle code and make it available for executive usage.

> Mark.

More information about the Openais mailing list