[Openais] Adding a service

Mark Haverkamp markh at osdl.org
Tue Jul 27 15:32:44 PDT 2004


On Tue, 2004-07-27 at 13:36, Steven Dake wrote:
> 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?
> > 
> 
> Mark,
> 
> 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.

I saw the ais_ci struct and plan on using it to track the per connection
data, essentially each saEvtInitialize call.  But each of those
instances can have multiple open channels.  When I get a library API
request for something associated with a given channel, I'd like a quick
way of accessing the data. With a handle I can have a quick look up of
data associated with a connection.  I think that I can make the channel
handle database be contained in the event instance data so that it
wouldn't be global.

Mark.

-- 
Mark Haverkamp <markh at osdl.org>




More information about the Openais mailing list