[Openais] Adding a service

[Steven Dake]

On Tue, 2004-07-27 at 15:32, Mark Haverkamp wrote:
> 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

OK I understand now, I haven't read thourougly the event spec.  I see
why you need the handle to be passed in.  By tracking them individually
the security implications are resolved.

I'll make some form of the handle database api available in the
executive for you probably today

Thanks!
-steve

> Mark.