[Sis-ams] better subject-matching?

[Ray, Timothy J. (GSFC-583.0)]

Thanks guys.  Not having been around from the beginning, I just wanted
to make sure that the idea had been considered.  Clearly it has, and
there are good reasons for the way things are.

 

Thanks,

Tim

 

________________________________

From: sis-ams-bounces at mailman.ccsds.org
[mailto:sis-ams-bounces at mailman.ccsds.org] On Behalf Of Scott Burleigh
Sent: Wednesday, September 10, 2008 9:08 PM
To: sis-ams at mailman.ccsds.org
Subject: Re: [Sis-ams] better subject-matching?

 

Edell, David J. wrote: 

Tim,

 

Advanced filtering options could have potential usage, and if I remember
correctly are available to some degree in the software bus of Goddard's
cFE.  I don't think its worth the added processing costs to change to a
string-based subject ID to accomplish that though.  

 

At a minimum, there's always the possibility of psuedo-filtering by
specifying ranges of subject-IDs for specific categories, which is
sometimes done on its own to organize ID listings.  This becomes an
implementation choice within a program though, rather than a
specification.  

 

I think the SubjectID, UnitID, RoleID field combination is intended to
give a similar effect in combination with the "all subject" and "all
role" subscription types.  It's been a while since I've looked at these
field definitions though, so I could be wrong.   This might be another
topic for discussion at Berlin.

You're right, David, that's exactly what the "domain" concept in
subscriptions, announcements, etc. is all about.

The problem here is that AMS is really intended to be for very high
performance (or, alternatively, for acceptable performance on highly
constrained hardware) in messaging, and string matching functions just
take a whole lot more processing time than integer comparison functions;
also, strings are typically a lot bigger than integers, so they consume
a lot more bandwidth -- not necessarily a big deal in Earth orbiters,
but a fairly big deal in deep space operations.  So the design decision
to use numeric subject IDs rather than strings was deliberate.

At the same time, the question of supporting more powerful subject
matching capability does come up over and over again; most (maybe all)
commercial message-oriented middleware systems have it.  The approach
we've been taking is to say that where these capabilities are needed you
presumably don't need high efficiency at the same time, so you can
afford an extra transmission hop, in which case the AMS Proxy
Architecture (section 6.1 of the spec) is the most flexible and powerful
way to provide this functionality.  I believe CNES, in fact, is already
contemplating development of a prototype AMQP-based AMS Proxy system.

Scott



________________________________

From: sis-ams-bounces at mailman.ccsds.org
[mailto:sis-ams-bounces at mailman.ccsds.org] On Behalf Of Ray, Timothy J.
(GSFC-583.0)
Sent: Wednesday, September 10, 2008 6:15 PM
To: sis-ams at mailman.ccsds.org
Subject: [Sis-ams] better subject-matching?

Hello all,

 

Does anyone see a (worthwhile) benefit to enhancing our subject-matching
capabilities to allow hierarchical subject-ids and some
pattern-matching?  Subjects would be transmitted as character strings
rather than 2-byte numbers, and subscribers would be able to specify
some sort of regular-expression format.

 

For example, if there were these subjects:

        Attitude.sun_sensor

        Attitude.momentum_wheel

        Attitude.gyros

 

Then an application might subscribe to   attitude.*   to receive all
subjects within the 'attitude' domain.

 

I don't think this enhancement is needed for the typical NASA/Goddard
mission, nor are any missions (that I'm aware of) asking for it.  Still,
it seems like something worth considering.  Does anyone have an opinion?

 

Tim

 

 



________________________________



 
_______________________________________________
Sis-ams mailing list
Sis-ams at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-ams
  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-ams/attachments/20080911/eb3c96d9/attachment.htm