ACK of register and purge packets

[[e-mail]]

Eric,

>I think that you missed the point (maybe?); because of the scenario in
>which a purge is not sent as a result of a component failure (crash),
>a "reliable purge" is an unattainable goal.

Unattainable in that scenario, but not others...

>This reduces the purge
>protocol to the status of "optimization" and it no longer makes sense
>to require purge originators to repeat purge messages until they are
>acknowledged.

An "optimization" in the "crash" scenario, but not all scenarios.

>As one member pointed out, that makes the case where a
>component is being taken off-line much simpler to handle as it not
>necessary for the component to wait for acknowledgement before
>continuing the power-down sequence (this could be critical for devices
>equiped with short-term back-up power provided for the express purpose
>of allowing for a graceful power-down).

For that critical case, *that* server could ignore the acknowledgements
and power down.  What harm would this cause in some special
scenarios?

>If it is not necessary to
>repeat purge messages until acknowledged, then acknowledgement becomes
>superfluous.

This is only true for servers or scenarios where the Purge
is not repeated.  However, I think we should keep the ack because
it will be used in some cases (eg, large holding times or
environments with requirement for super-rapid convergence...).

>
>
>
>                                 Eric Gray

-- Russell