[Sis-ams] notation for delivery point names

[Scott Burleigh]

Stuart Fowell wrote:
> Scott,
>  
> There is a two steps to processing a delivery point name:
>  
> 1. Do I support the underlying transport service
> 2. If 1 is true, then can I use it to transfer to the destination
>  
> Step 2 is particular to the underlying transport service - this allows 
> for different formats etc for different underlying transport service 
> types.
>  
> "vxmq2113451256:11311876" merges the two together whereas 
> "vxmq:2113451256:11311876" separates these two steps into independent 
> information
>  
> FYI, this is the mechanism that CORBA uses, with an ID for each 
> transport type so that a particular ORB implementation only needs to 
> process those transport types that it supports.
Sure, it's an intuitively obvious approach, and it is certainly doable.  
My point is just that the other way will run a bit faster and is simpler 
to code in a general way: merging the two steps together enables both to 
be accomplished in a single search loop, with a single string 
comparison, without requiring additional generalized logic (an 
additional callback function pointer, for example) to do step 2.  It's a 
very inexpensive design optimization.

Scott
> ------------------------------------------------------------------------
> *From:* sis-ams-bounces at mailman.ccsds.org 
> [mailto:sis-ams-bounces at mailman.ccsds.org] *On Behalf Of *Scott Burleigh
> *Sent:* 08 November 2008 00:24
> *To:* sis-ams at mailman.ccsds.org
> *Subject:* [Sis-ams] notation for delivery point names
>
> Hi, gang.  At the October meetings we left one spec issue unresolved, 
> because it seemed subtle and complex enough to deserve some off-line 
> thought and discussion by email.  That issue was the notation we use 
> for delivery point names.
>
> The spec currently says that a delivery point name is the 
> concatenation of a transport service name, an equals ('=') sign, and 
> an endpoint name in transport-service-specific format.  Currently the 
> syntax of the transport service name for TCP is the intuitively 
> obvious "tcp", and endpoint names are in the similarly obvious format 
> /hostname/:/portnumber/; likewise for UDP.  But for VxWorks message 
> queues the spec says the transport service name is "vxmq/hostnumber/", 
> with /msgqID /as the endpoint name.  The idea under discussion, as I 
> recall, was to simplify the protocol by using the general structure 
> /protocolname/:/qualifier/:/qualifier/:...:/qualifier /for all 
> delivery point names, e.g. "tcp:amroc.jpl.nasa.gov:5453" and 
> "vxmq:2113451256:11311876".
>
> I've given this some thought and have concluded that, while I agree 
> that the proposed notation's generality is appealing, this is one of 
> those rare cases where the more intuitively elegant approach is 
> disadvantageous in implementation.
>
> The intent of the current design is to simplify the processing of 
> delivery vectors in MAMS messages: a receiving MAMS entity can always 
> know whether or not a given delivery point is one that it can use for 
> message transmission to the sending entity, simply by looking for the 
> '=' character and then comparing the preceding character string to the 
> names of the transport services to which it has access.
>
> The proposed design is, paradoxically, more complex.  In the case of 
> "tcp:amroc.jpl.nasa.gov:5453" the receiving entity would know that the 
> delivery point is usable if "tcp" -- the token preceding the first 
> colon -- is one of its transport services.  But in the case of 
> "vxmq:2113451256:11311876" the delivery point would be usable only if 
> "vxmq:2113451256" -- the string preceding the *second* colon -- was 
> one of its transport services, because message-queue transport is 
> possible only between tasks residing on the same machine.  Tasks 
> residing on different computers running VxWorks cannot exchange 
> messages among themselves via message queue; "vxmq" alone would not be 
> enough to assure connectivity.
>
> In order to make the proposed syntax work, we would have to build 
> transport-service-specific rules into the code that processes delivery 
> vectors in inbound MAMS messages, indicating how much of the delivery 
> point name constitutes the transport service name.  To avoid adding 
> any more complexity to an already complex specification, I think we 
> should stick with the current notation.  Does anyone have strong 
> feelings otherwise?
>
> Scott
>  
> SciSys UK Limited. Registered in England and Wales No. 4373530.
> Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.
>  
> P Before printing, please think about the environment.

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