[Sis-ams] Re: AMS

[Scott Burleigh]

Edell, David J. wrote:
> Scott (& Pat),
>  
> This is one case where our APL-AMS is a bit non-standard, in that we 
> are using POSIX message queues as our primary/only transport service.
Well, that in itself isn't non-standard at all.  But it may make 
implementation awkward in some ways.
> Using this method, we have no data from the transport service to 
> indicate a message's origin.
Okay, but I can think of a work-around.  Imagine we're inventing a "new" 
transport service protocol named "psmq".  Every AMS communicating entity 
has an associated POSIX message queue that it (and it alone) reads MAMS 
messages from but all entities can write MAMS messages to.  All psmq 
PDUs are carried via these POSIX message queues, and each psmq protocol 
data unit consists of a MAMS message preceded by the ID of the message 
queue that is associated with the entity that sent this psmq PDU.  Now 
whenever any AMS communicating entity reads a psmq PDU it gets a MAMS 
plus enough information to send a reply.  
> An alternative, may be to designate the unused supplementary data in 
> these query messages as "reserved for optional transport service 
> extensions," indicating that the PTS may optionally include additional 
> routing/configuration information (ie: MAMS endpoint) if required.  
> The field would otherwise be ignored by other transport services, 
> which would accordingly set the supplement data length to 0 when 
> populating these messages. This would free the protocol from 
> additional limitations on the transport service, without placing any 
> unnecessary burden on the standard transport services.
I'm inclined to prefer adding an extra "layer" (as above) rather than 
overload fields in the MPDU for transport-specific purposes, but that 
may be unnecessary conservatism.  
> The registrar transmits the you_are_dead message in response to a 
> node's heartbeat timeout, which is what I was referring to.
David, can you point to the section of the spec that says this happens?  
I don't believe that's the defined behavior, and I don't think it's 
necessary.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-ams/attachments/20080509/1f69d1d2/attachment.html