Harry,
Whenever the SENSE server sends an event message to a subscriber,
the server periodically retransmits the event until the subscriber
sends a reply. Of course, there are limits as to the number of
retransmits, and the overall TTL (time to live) of the message to
limit the resources required by the server.
Similarly, a publisher (the agent submitting events to the server
on behalf of an "entity", in this case, a printer) uses the same
approach in submitting events; the publisher periodically retries
until the server acknowledges receipt of the event, with the same
types of max-retries and TTL as above.
In the manner, we get what we refer to as "reasonable reliability".
Comments from anyone? Is this "good enough"?
...jay
--=_ORCL_30656829_0_11919702132325530
Content-Type:message/rfc822
Date: 13 Feb 97 12:31:15
From:"Harry Lewis <harryl@vnet.ibm.com> <harryl@VNET.IBM.COM>" <sense-owner@pwg.org>
To:jds@underscore.com,sense@pwg.org
Subject:SENSE> SENSE clarifications
Return-Path:<sense-owner@pwg.org>
Sender:owner-sense@pwg.org
MIME-Version: 1.0
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
Jeff, thanks for your previous clarification that the Step.1 protocol
rides in the Opaque Data field of the SENSE message. I should have known.
It's all very clear following your explanation.
One more question. I've heard Jay refer to the UDP nature of SENSE as a
salability plus, but where is the acknowledgment scheme specified that
makes the SENSE message reliable?
Harry Lewis.
--=_ORCL_30656829_0_11919702132325530--