<!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">
Edell, David J. wrote:
<blockquote
 cite="mid:FEEF8FE8A931BE478D2538A677C48BED0343BF8C@aplesjustice.dom1.jhuapl.edu"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.3268" name="GENERATOR">
  <div dir="ltr" align="left"><font color="#0000ff" face="Arial"
 size="2"><span class="199561720-05052008">Scott (&amp; Pat),</span></font></div>
  <div dir="ltr" align="left"><font color="#0000ff" face="Arial"
 size="2"><span class="199561720-05052008"></span></font>&nbsp;</div>
  <div dir="ltr" align="left"><font color="#0000ff" face="Arial"
 size="2"><span class="199561720-05052008">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.</span></font></div>
</blockquote>
Well, that in itself isn't non-standard at all.&nbsp; But it may make
implementation awkward in some ways.<br>
<blockquote
 cite="mid:FEEF8FE8A931BE478D2538A677C48BED0343BF8C@aplesjustice.dom1.jhuapl.edu"
 type="cite">
  <div dir="ltr" align="left"><font color="#0000ff" face="Arial"
 size="2"><span class="199561720-05052008">Using this method, we have
no data from the transport service to indicate a message's origin.</span></font></div>
</blockquote>
Okay, but I can think of a work-around.&nbsp; Imagine we're inventing a
"new" transport service protocol named "psmq".&nbsp; 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.&nbsp;
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.&nbsp; Now whenever any AMS communicating entity reads a psmq PDU it
gets a MAMS plus enough information to send a reply.<font
 color="#0000ff" face="Arial" size="2"><span class="199561720-05052008"></span></font>
<font color="#0000ff" face="Arial" size="2"><span
 class="199561720-05052008"></span></font>&nbsp;
<blockquote
 cite="mid:FEEF8FE8A931BE478D2538A677C48BED0343BF8C@aplesjustice.dom1.jhuapl.edu"
 type="cite">
  <div dir="ltr" align="left"><font color="#0000ff" face="Arial"
 size="2"><span class="199561720-05052008">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.&nbsp; 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.</span></font></div>
</blockquote>
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.
<font color="#0000ff" face="Arial" size="2"><span
 class="199561720-05052008"></span></font>&nbsp;
<blockquote
 cite="mid:FEEF8FE8A931BE478D2538A677C48BED0343BF8C@aplesjustice.dom1.jhuapl.edu"
 type="cite">
  <div dir="ltr" align="left"><font color="#0000ff" face="Arial"
 size="2"><span class="199561720-05052008">The registrar transmits the
you_are_dead message in response to a node's heartbeat timeout, which
is what I was referring to.</span></font></div>
</blockquote>
David, can you point to the section of the spec that says this
happens?&nbsp; I don't believe that's the defined behavior, and I don't
think it's necessary.<br>
<br>
Scott<br>
</body>
</html>