<!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 (& Pat),</span></font></div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"
size="2"><span class="199561720-05052008"></span></font> </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. 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. 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.<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>
<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. 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>
<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? I don't believe that's the defined behavior, and I don't
think it's necessary.<br>
<br>
Scott<br>
</body>
</html>