<!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">
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.<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. 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. 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. 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. 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.<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. 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?<br>
<br>
Scott<br>
</body>
</html>