[Sis-ams] minor heartbeat-related issue
Donahue, Pat
pat.donahue at nasa.gov
Thu Jul 10 13:21:31 EDT 2008
opinion - the third alternative is good enough, because ...
When the Registrar doesn't get Heartbeat from the Configuration server,
Registrar will eventually re-try to do an ANNOUNCE_REGISTRAR with its
Unit Number. It will either be successfully registered by the
Configuration server, or rejected if another Registrar already has that
Unit Number - in which case our lonely Registrar should shut down. Am I
remembering it all right?
Patrick Donahue
(256) 544-5943 office
(256) 721-0726 home
(256) 682-9753 cell
________________________________
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 11:53 AM
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/e3c6cf0c/attachment.html
More information about the Sis-ams
mailing list