[Sis-ams] minor heartbeat-related issue

[Ray, Timothy J. (GSFC-583.0)]

Scott,

 

Yes, I agree that the third alternative seems best.  

 

Tim

 

 

________________________________

From: sis-ams-bounces at mailman.ccsds.org
[mailto:sis-ams-bounces at mailman.ccsds.org] On Behalf Of Scott Burleigh
Sent: Thursday, July 10, 2008 12:53 PM
To: sis-ams at mailman.ccsds.org
Subject: Re: [Sis-ams] minor heartbeat-related issue

 

Edell, David J. wrote: 

I ran into a similar issue when finishing my implementation.  

 

I believe the intent was for the reply method to be inferred from the
transport service in that case--meaning that this is a piece of data
missing in the AMS content itself.  In my case, I think the node-id was
included which I used in the absence of TS specified context to infer
the reply address in the APL implementation for unregistered nodes
(which uses a direct mapping). I don't remember if/how I had addressed
this for an unregistered registrar.

David's answer is right, and I realize this may not be wholly
satisfactory.  There's an implicit expectation that the receiving entity
can figure out the MAMS endpoint name of the sender in a
transport-specific way that is left as an implementation issue.  For
example, if you're using UDP as the transport for MAMS traffic then when
you receive the heartbeat you can get the IP address and port number of
the sending socket from the recvfrom() parameters and send the
you_are_dead message back to that socket.  You'd have similar
information if you used, say, the DTN Bundle Protocol as your MAMS
transport protocol.  This is one of the main reasons that TCP, for
example, is not a particularly good choice as a MAMS transport protocol:
the asymmetry of connect/accept makes this kind of echoing complex to
implement.

At minimum (I now realize), this implementation responsibility ought to
be made explicit somewhere -- probably in 4.2.7.4.4 and 4.2.7.4.5,
although I guess a case could be made for documenting it in the Green
Book instead.

Alternatively, we could modify the heartbeat message to carry MAMS
endpoint name.  I am not real comfortable with this, as I think it would
be perceived as adding a lot of bandwidth consumption that would be
needed only in two edge cases.

A third alternative, though, might be simply to ditch the transmission
of you_are_dead messages in these cases, i.e., just ignore the
heartbeats.  The only downside of this would be that the unregistered
entity wouldn't receive such prompt notification that it is not
currently registered.  But eventually it would drop back into imputed
termination logic and go through the relevant re-registration procedure,
so there's no real harm done.

On reflection, I like this third alternative pretty well.  What do you
all think?

Scott



________________________________

From: sis-ams-bounces at mailman.ccsds.org
[mailto:sis-ams-bounces at mailman.ccsds.org] On Behalf Of Ray, Timothy J.
(GSFC-583.0)
Sent: Wednesday, July 09, 2008 2:51 PM
To: sis-ams at mailman.ccsds.org
Subject: [Sis-ams] minor heartbeat-related issue

Dear WG members,

 

(Scott:  thanks for posting the latest specs, and for keeping them
up-to-date.)

 

Here's another issue that I've run into.  Perhaps I am missing
something?

 

4.2.7.4.4 - If a server receives a 'heartbeat' from an unregistered
registrar, it is supposed to send back a 'you-are-dead'.  In order to do
that, it will need to know how to contact the registrar (i.e. its
mams-endpoint-name).  That name is not included in the 'heartbeat'.  How
can a server send an MPDU to an unregistered registrar?

 

4.2.7.4.5 - Same as previous, but registrar receives a heartbeat from an
unregistered node.

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