<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Stuart Fowell wrote:
<blockquote
 cite="mid:3258DBDEDE979E4DBEEC0565338E181E010D0DE4@mx-bri-exch0.scisys.co.uk"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.3354" name="GENERATOR">
  <div dir="ltr" align="left"><span class="698082910-11112008"><font
 color="#0000ff" face="Tahoma" size="2">Scott,</font></span></div>
  <div dir="ltr" align="left"><span class="698082910-11112008"></span>&nbsp;</div>
  <div dir="ltr" align="left"><span class="698082910-11112008"><font
 color="#0000ff" face="Tahoma" size="2">There is a two steps
to&nbsp;processing a delivery point name:</font></span></div>
  <div dir="ltr" align="left"><span class="698082910-11112008"></span>&nbsp;</div>
  <div dir="ltr" align="left"><span class="698082910-11112008"><font
 color="#0000ff" face="Tahoma" size="2">1. Do I support the underlying
transport service</font></span></div>
  <div dir="ltr" align="left"><span class="698082910-11112008"><font
 color="#0000ff" face="Tahoma" size="2">2. If 1 is true, then can I use
it to transfer to the destination</font></span></div>
  <div dir="ltr" align="left"><span class="698082910-11112008"><font
 face="Tahoma" size="2">
  <div dir="ltr" align="left"><span class="698082910-11112008"></span>&nbsp;</div>
  <div dir="ltr" align="left"><span class="698082910-11112008"><font
 color="#0000ff" face="Tahoma" size="2">Step 2 is particular to the
underlying transport service - this allows for different formats etc
for different underlying transport service types.</font></span></div>
  <div dir="ltr" align="left"><span class="698082910-11112008"></span>&nbsp;</div>
  </font></span></div>
  <div dir="ltr" align="left"><span class="698082910-11112008"><font
 color="#0000ff">
  </font>
  <div dir="ltr" align="left"><span class="698082910-11112008"><font
 color="#0000ff"><font color="#0000ff">"vxmq2113451256:11311876" merges
the two together whereas </font></font></span><font color="#0000ff">"vxmq:2113451256:11311876"
separates these two steps into independent information</font></div>
  </span></div>
  <div>&nbsp;</div>
  <div><span class="698082910-11112008"><font color="#0000ff"
 face="Tahoma" size="2">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.</font></span></div>
</blockquote>
Sure, it's an intuitively obvious approach, and it is certainly
doable.&nbsp; 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.&nbsp; It's
a very inexpensive design optimization.<br>
<br>
Scott<br>
<blockquote
 cite="mid:3258DBDEDE979E4DBEEC0565338E181E010D0DE4@mx-bri-exch0.scisys.co.uk"
 type="cite">
  <div class="OutlookMessageHeader" dir="ltr" align="left" lang="en-us">
  <hr tabindex="-1"><font face="Tahoma" size="2"><b>From:</b>
<a class="moz-txt-link-abbreviated" href="mailto:sis-ams-bounces@mailman.ccsds.org">sis-ams-bounces@mailman.ccsds.org</a>
[<a class="moz-txt-link-freetext" href="mailto:sis-ams-bounces@mailman.ccsds.org">mailto:sis-ams-bounces@mailman.ccsds.org</a>] <b>On Behalf Of </b>Scott
Burleigh<br>
  <b>Sent:</b> 08 November 2008 00:24<br>
  <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:sis-ams@mailman.ccsds.org">sis-ams@mailman.ccsds.org</a><br>
  <b>Subject:</b> [Sis-ams] notation for delivery point names<br>
  </font><br>
  </div>
Hi, gang.&nbsp; 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.&nbsp; That issue was the notation we use
for delivery point names.<br>
  <br>
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.&nbsp; Currently the syntax of the
transport service name for TCP is the intuitively obvious "tcp", and
endpoint names are in the similarly obvious format <i>hostname</i>:<i>portnumber</i>;
likewise for UDP.&nbsp; But for VxWorks message queues the spec says the
transport service name is "vxmq<i>hostnumber</i>", with <i>msgqID </i>as
the endpoint name.&nbsp; The idea under discussion, as I recall, was to
simplify the protocol by using the general structure <i>protocolname</i>:<i>qualifier</i>:<i>qualifier</i>:...:<i>qualifier
  </i>for all delivery point names, e.g. "tcp:amroc.jpl.nasa.gov:5453"
and "vxmq:2113451256:11311876".<br>
  <br>
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.<br>
  <br>
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.<br>
  <br>
The proposed design is, paradoxically, more complex.&nbsp; 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.&nbsp; 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.&nbsp; Tasks residing on
different computers running VxWorks cannot exchange messages among
themselves via message queue; "vxmq" alone would not be enough to
assure connectivity.<br>
  <br>
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.&nbsp; To avoid adding any
more complexity to an already complex specification, I think we should
stick with the current notation.&nbsp; Does anyone have strong feelings
otherwise?<br>
  <br>
Scott<br>
<!--[object_id=#scisys.co.uk#]--><font face="Tahoma" size="2"><font
 color="#0000ff">
  <div align="left">&nbsp;</div>
  <div align="left"><font color="#808080" face="Tahoma" size="2">SciSys
UK Limited. Registered in England and Wales No.&nbsp;4373530.</font></div>
  <div align="left"><font color="#808080" face="Tahoma" size="2">Registered
Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.</font></div>
  <div align="left">&nbsp;</div>
  <div align="left"><span class="400184714-12042007"><font
 color="#008000" face="Webdings" size="4">P</font><font color="#000000"><font
 face="Tahoma"><font size="4"> </font><span
 style="font-size: 7pt; font-family: Tahoma;"><font size="1"><font
 color="#008000">Before printing,&nbsp;<span class="296245114-12042007">please
  </span>think about the environment<span class="296245114-12042007">.</span></font></font></span></font></font></span></div>
  </font></font></blockquote>
<br>
</body>
</html>